OffNet Newsroom

Daily topic roundup

Database Technology

Sunday, September 06, 2026 · 8 stories, curated & summarized — click any story for the source.

Christophe Pettus reviews four legacy logging parameters in PostgreSQL that track CPU time, page faults, and context switches for individual statements. These metrics provide low-level operational visibility into query execution costs that modern tools often obscure. They remain essential for diagnosing performance bottlenecks where standard slow query logs are insufficient.

  • Use log_parser_stats to measure parsing overhead and CPU time spent on query analysis.
  • Enable log_planner_stats to identify expensive query planning phases and optimization choices.
  • Log executor stats to pinpoint execution time, page faults, and context switch costs.
  • Combine all four GUCs for a complete picture of statement-level resource consumption.
  • These crude metrics are irreplaceable for deep-dive performance root cause analysis.
CHECKLISTEnable Legacy GUCsLog parser stats for parsing overheadLog planner stats for optimization choicesLog executor stats for execution costsCombine all for full resource picture
AWS What's New awsdatabase ↺ since 09-04

Aurora MySQL 8.4.8 GA: PQ-TLS, Multi-Source Replication, and Transaction Timeouts

Amazon Aurora MySQL-Compatible Edition 8.4.8 is now generally available, bringing security enhancements and new replication capabilities. Key additions include post-quantum TLS for data-in-transit encryption, configurable transaction timeouts to mitigate InnoDB purge blocks, and multi-source replication for sharding consolidation. The release also supports delayed replication to safeguard against accidental data loss.

  • Post-quantum TLS (PQ-TLS) key exchange is now supported for encrypting data in-transit.
  • Transaction timeouts help prevent performance degradation from long-running transactions blocking InnoDB purge.
  • Multi-source replication enables consolidating data from multiple sources into a single replica.
  • Delayed replication allows configurable lag to protect against accidental data modifications.
  • Verify application compatibility with MySQL 8.4.8 before upgrading your Aurora cluster.
CHECKLISTAurora 8.4.8 Upgrade ChecklistVerify app compatibility with MySQL 8.4.8Enable post-quantum TLS for encryptionConfigure transaction timeouts to fix purge blocksUse multi-source replication for shardingSet delayed replication for safety
AWS Database Blog awsdatabase ↺ since 09-04

Troubleshooting Aurora Global DB Write Forwarding in AWS Advanced JDBC Wrapper

The AWS Advanced JDBC Wrapper requires precise region-specific configuration to enable write forwarding in Aurora Global Database setups. Incorrect dialects, plugins, or host patterns lead to latency spikes and connection failures. This guidance details the correct settings for both primary and secondary regions to ensure stable routing.

  • Misconfigured dialects or plugins in the wrapper cause immediate latency spikes.
  • Host patterns must be explicitly defined for both primary and secondary regions.
  • Write forwarding settings differ between primary and secondary region configurations.
  • Region-specific settings are mandatory to prevent connection failures during failover.
AWS Database Blog awsdatabase ↺ since 09-03

AWS DMS AI agents automate SQL Server to Aurora PostgreSQL conversion

AWS has introduced AI agents within AWS DMS Schema Conversion to orchestrate migrations from SQL Server to Amazon Aurora PostgreSQL using natural language prompts. The agent drives the workflow by processing T-SQL and guiding users through decision frameworks to resolve common incompatibilities and CRITICAL action items. This approach aims to streamline the schema conversion process by reducing manual intervention for complex translation tasks.

  • Use natural language prompts to drive AWS DMS Schema Conversion workflows for SQL Server to Aurora PostgreSQL.
  • AI agents assist in resolving CRITICAL action items via built-in decision frameworks for incompatibilities.
  • The engine automatically processes T-SQL syntax during the schema conversion phase.
  • Reduces manual effort in interpreting error logs and applying translation rules.
  • Integrates directly into existing AWS DMS migration pipelines for schema-only or full loads.
Planet PostgreSQL database ↺ since 09-05

PostgreSQL 19 Beta 3 released with compatibility breaks and SQL additions

PostgreSQL 19 Beta 3 shipped on August 13, 2026, with general availability projected for the coming weeks based on the project's typical cadence. The release introduces specific SQL-level features and compatibility breaks that require careful review before upgrading. This update follows the pattern of previous major releases, focusing on practical changes rather than a full changelog dump.

  • PostgreSQL 19 Beta 3 is available for testing and evaluation now.
  • Expect GA release within the next few weeks following September/October patterns.
  • Review compatibility breaks to avoid upgrade failures in production environments.
  • New SQL additions are designed for immediate practical utility in queries.
CHECKLISTPostgreSQL 19 Beta 3 ActionsTest Beta 3 in non-production environments immediatelyReview compatibility breaks to prevent upgrade failuresEvaluate new SQL features for practical utilityPrepare for GA release within weeks
Planet PostgreSQL database ↺ since 09-04

Postgres Join Collapse Limit Causes Query Plan Regression

Adding a small lookup table to a complex query can trigger a drastic plan shift from nested loops to hash joins due to the join_collapse_limit setting. This threshold, defaulting to 8 tables since 2005, causes performance cliffs that do not exist in SQL Server or MySQL. Benchmarks using ExoBench confirm this behavior flips execution time from sub-millisecond to hundreds of milliseconds.

  • Postgres join_collapse_limit defaults to 8, causing plan flips when queries exceed this table count.
  • Adding small dimension tables can degrade performance by forcing expensive hash joins over nested loops.
  • SQL Server and MySQL lack this specific cliff, making cross-engine comparisons tricky.
  • Monitor query plans when adding new joins to existing complex billing or reporting queries.
Planet PostgreSQL database ↺ since 09-02

PostgreSQL 19 Beta Introduces Four New System Views for Observability

PostgreSQL 19 adds four new system views to enhance monitoring and diagnostics: pg_stat_lock, pg_stat_recovery, pg_stat_autovacuum_scores, and pg_dsm_registry_allocations. This marks the first significant expansion of system views since versions 13 and 14, reflecting a continued focus on observability. The author notes that the release is still in beta, so column names and features may change before general availability.

  • Four new views target lock contention, recovery status, autovacuum efficiency, and dynamic shared memory.
  • pg_stat_autovacuum_scores provides granular metrics to tune vacuuming strategies effectively.
  • pg_dsm_registry_allocations exposes dynamic shared memory usage for deeper performance analysis.
  • Beta status means schema details may shift; verify against final release notes before production planning.
  • This update signals Postgres's ongoing commitment to richer telemetry without external agents.
AWS What's New awsdatabase ↺ since 09-03

AWS RDS SQL Server adds 18 trace flags for fine-tuned performance control

Amazon RDS for SQL Server now allows enabling 18 additional SQL trace flags via database parameter groups. These flags modify engine behavior for areas like query optimization, lock escalation, and memory handling. This update gives DBAs greater flexibility to address workload-specific challenges directly within the managed environment.

  • Enables 18 new trace flags (e.g., 647, 9432, 12618) for granular SQL Server tuning.
  • Manage flags via database parameter groups for easier configuration and lifecycle management.
  • Optimize query plans, DDL performance, and memory handling without OS-level access.
  • Stabilize workloads by addressing specific engine behaviors like cardinality estimation.

Fleet impact: For SQL Server on RDS, you can now tune query optimizer and memory behaviors via parameter groups, reducing the need for workarounds. Check your workload against the new flags (e.g., 9432 for cardinality) to resolve specific plan or performance issues without external support.

BY THE NUMBERSNew Trace Flags for SQL Server18Additional trace flags enabledGranular control for query and memory tuning
↑