OffNet Newsroom

Daily topic roundup

Database Technology

Tuesday, August 25, 2026 · 8 stories, curated & summarized — click any story for the source.

AWS What's New awsdatabase

AWS RDS for MySQL 8.4.11 adds post-quantum TLS support

Amazon RDS for MySQL has added support for minor version 8.4.11, bringing operational improvements and community bug fixes. A key addition is post-quantum TLS (PQ-TLS) key exchange for encrypting data in transit. Users are advised to upgrade to address CVEs and leverage automatic minor version upgrades.

  • RDS for MySQL now supports community version 8.4.11
  • Post-quantum TLS key exchange enables PQ cryptography in transit
  • Upgrade to patch CVEs and gain performance improvements
  • Use automatic minor version upgrades to stay current
CHECKLISTUpgrade To MySQL 8.4.11Enable post-quantum TLS for transit encryptionPatch CVEs with latest minor versionActivate automatic minor version upgrades

Christophe Pettus highlights that PostgreSQL automatically transitions prepared statements from custom to generic plans after the sixth execution. This hard-coded threshold can cause queries to become mysteriously slow if the generic plan is suboptimal compared to the initial custom plans. The behavior is a known mechanism to prevent excessive planning overhead but can negatively impact performance in specific workloads.

  • PostgreSQL switches to generic plans after exactly six executions of a prepared statement.
  • This change can lead to sudden performance degradation if the generic plan is inefficient.
  • Monitor slow queries in logs to identify if they are affected by this plan switch.
  • Consider disabling prepared statements or adjusting workloads if this threshold causes issues.
HOW IT WORKSPostgreSQL Plan Switching Pipeline1Execute prepared statement2Generate custom plan3Run query again4Repeat until sixth execution5Switch to generic plan

Amazon Aurora PostgreSQL-Compatible Edition has added support for PostgreSQL minor versions 18.4, 17.10, 16.14, 15.18, and 14.23. These releases incorporate community bug fixes, Aurora-specific enhancements, and patches for known Common Vulnerabilities and Exposures. AWS recommends upgrading during scheduled maintenance windows to ensure security and performance stability.

  • Upgrade to latest minor versions to patch known CVEs and access bug fixes.
  • Enable automatic minor version upgrades to simplify operational overhead.
  • Use AWS Organizations Upgrade Rollout Policy for phased, safe deployments.
  • Validate upgrades in lower-priority environments before touching critical databases.
CHECKLISTSafe Aurora Upgrade StepsUpgrade to latest minor versions to patch CVEsEnable automatic minor version upgrades to reduce overheadUse AWS Organizations policy for phased deploymentsValidate upgrades in lower environments first

The pg_statviz extension has reached version 1.2, bringing compatibility with PostgreSQL 19 betas and maintaining support for versions 13 through 19. This update introduces new data capture capabilities, including the wal_fpi_bytes counter and detailed configuration snapshots for I/O workers and autovacuum settings. A significant addition is the blocking locks analysis module, which leverages pg_blocking_pid to track session contention and break down lock types by relation, transaction ID, and tuple.

  • Captures new wal_fpi_bytes counter from pg_stat_wal for PostgreSQL 19.
  • Snapshot_conf now records PG18/19 I/O worker and autovacuum scoring details.
  • New blocking locks module tracks blocked/blocking sessions via pg_blocking_pid.
  • Lock type breakdown covers relation, transactionid, and tuple categories.
  • Validated against PostgreSQL 19 beta3 and supports range 13 to 19.
COMPARISONPostgreSQL Versions SupportedEarliest Version13I/O Worker Support18Latest Version19

Christophe Pettus explores the complex landscape of PostgreSQL logging GUCs, tracing their evolution since version 8.3 when autovacuum and distributed checkpoints became standard. The post details how settings like log_checkpoints, log_autovacuum_min_duration, and log_temp_files provide visibility into internal housekeeping operations. It serves as a guide for tuning these parameters to capture essential performance data without overwhelming the log stream.

  • Enable log_checkpoints to monitor I/O spikes and WAL generation patterns.
  • Tune log_autovacuum_min_duration to identify long-running vacuum processes.
  • Use log_temp_files to detect query plans causing excessive disk sorting.
  • Review GUC interactions to balance diagnostic granularity against log volume.
  • Leverage these logs for proactive capacity planning and performance tuning.

DuckDB Labs has previewed version 2.0, codenamed Cyanoptera, which introduces a client/server architecture allowing network connections beyond its traditional embedded model. The release features over 10,000 commits, including a new parser, improved extension portability, and performance boosts via asynchronous I/O. General availability is targeted for fall 2026.

  • Shifts DuckDB from embedded-only to a client/server model with network support.
  • Includes over 10,000 commits and a new parser for better stability.
  • Asynchronous I/O and storage optimizations improve query performance.
  • GA expected in fall 2026; current preview is for testing only.
Planet PostgreSQL database

PostGIS 3.7.0rc1 Released with PostgreSQL 19 Beta Support

The PostGIS team has issued the first release candidate for version 3.7.0, targeting PostgreSQL 14 through 19rc1. This build includes bug fixes since beta2 and new features, requiring GEOS 3.10+ with 3.15+ recommended for full functionality. It also integrates postgis_tiger_geocoder 2025.2 and supports SFCGAL 2.3.0+ for advanced geometry operations.

  • Test compatibility with PostgreSQL 19 Beta 3 if upgrading soon.
  • Upgrade GEOS to 3.15+ to access all new PostGIS capabilities.
  • Check SFCGAL version (2.3.0+) for advanced spatial algorithm support.
  • Review bug fixes since 3.6.4 for regression risks in production.
  • Verify postgis_tiger_geocoder 2025.2 integration with existing workflows.

Alexey Evlampiev introduces a testing pattern where business logic branches are modeled as a directory tree. By using database savepoints, each test branch inherits the transactional history of its parent, eliminating redundant state setup. This approach allows a traversal algorithm to walk the scenario tree and determine if the deployment logic commits successfully based on shared history.

  • Use savepoints to create branchable test scenarios that inherit prior state.
  • Eliminate redundant data setup by sharing transaction history across branches.
  • Model business logic paths as a directory tree for structured traversal.
  • Automate commit validation by walking the scenario tree programmatically.
↑