OffNet Newsroom

Daily topic roundup

Database Technology

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

AWS Database Blog awsdatabase

AWS guides troubleshooting MySQL query regressions post-upgrade

AWS explains how major or minor MySQL engine upgrades can trigger query regressions due to shifts in optimizer cost models, defaults, and execution strategies. The blog details a diagnostic workflow designed to trace each regression back to the specific version change that caused it. It then outlines the appropriate fixes to resolve these performance issues.

  • Upgrades alter optimizer cost models and defaults, causing unexpected query regressions.
  • Use the provided workflow to trace regressions to specific version changes.
  • Apply targeted fixes identified through the diagnostic process to restore performance.

Christophe Pettus corrects a previous sizing guideline, clarifying that since PostgreSQL 12, WAL sender processes are allocated separately via max_wal_senders and do not consume slots from max_connections. This distinction is critical for accurately sizing the maximum number of concurrent client connections. The rest of the original advice on connection management remains valid.

  • PostgreSQL 12+ decouples replication connections from max_connections.
  • Size max_wal_senders independently for your replication topology.
  • Do not add replication slots to your max_connections budget.
  • Review existing sizing logic if running PG 12 or newer.

Meta has released ZGateway, a stateless proxy designed to manage connections and route traffic for its ZippyDB storage system. The gateway currently processes over 1 billion operations per second, accounting for approximately 40% of total ZippyDB traffic. By centralizing load balancing, caching, and admission control, the system achieves a 19x reduction in persistent database connections.

  • Stateless architecture simplifies deployment and scaling without maintaining session state.
  • 19x connection reduction lowers resource overhead and simplifies connection pool management.
  • Handles 1B+ ops/sec with only 40% of traffic routed, proving significant capacity headroom.
  • Centralized admission control and caching improve traffic predictability and latency.

Percona Toolkit’s pt-online-schema-change uses dynamic chunk sizing to adapt to production workloads during large table migrations. However, this auto-resize mechanism can backfire when used with Galera clusters, potentially triggering flow control issues. The article explains how the interaction between chunk growth and Galera replication mechanics can create counterproductive performance bottlenecks.

  • pt-osc chunk auto-resize is designed for workload adaptation but may harm Galera clusters.
  • Dynamic chunk growth can trigger Galera flow control, stalling replication.
  • Monitor Galera flow control metrics when running pt-osc on large tables.
  • Consider limiting chunk size or using alternative tools for Galera environments.
CHECKLISTSafe pt-osc on GaleraMonitor Galera flow control metrics closelyLimit chunk size to prevent stallsConsider alternative tools for Galera

A production strategy using ALTER FUNCTION SET work_mem allows targeted memory allocation for specific functions, preventing sort operations from spilling to disk. This approach eliminates the need for risky global configuration changes while significantly reducing I/O overhead. The technique successfully reduced daily disk spill volume from 150 GB to zero in a real-world scenario.

  • Target work_mem at the function level to isolate memory-heavy sorts without affecting other sessions.
  • Avoid global work_mem increases to prevent OOM risks for concurrent connections.
  • Eliminate expensive disk spill I/O for specific queries, boosting throughput.
  • Use ALTER FUNCTION to apply persistent, granular memory settings per function.

Amazon DocumentDB engine version 8.0.2 now supports retryable writes, allowing the MongoDB driver to automatically retry write operations once during transient errors like network interruptions or primary failovers. This capability is enabled by default in most current drivers, removing the need for applications to set retryWrites=false in the connection string. The feature applies to all write commands except updateMany, significantly improving application resilience without requiring code changes.

  • Upgrade to DocumentDB engine 8.0.2 to enable retryable writes support.
  • Drivers automatically retry writes on transient errors, boosting resilience.
  • No code changes needed; drivers handle retries by default.
  • Remove retryWrites=false from connection strings to avoid conflicts.
  • Not supported for updateMany commands.
CHECKLISTImplementing Retryable WritesUpgrade to DocumentDB engine 8.0.2Remove retryWrites=false from connection stringsDrivers handle retries automaticallyNo code changes requiredExcludes updateMany commands

Amazon DocumentDB version 8.0.2 introduces retryable writes for transient errors, enhancing resilience during failovers. The release adds support for five new aggregation stages, including $setWindowFields, $bucketAuto, $facet, $graphLookup, and correlated $lookup. These updates expand MongoDB API compatibility and improve query performance for advanced analytics and hierarchical queries.

  • Retryable writes auto-retry transient errors, reducing manual error handling in apps.
  • New aggregation stages enable window functions, faceted search, and graph traversal.
  • Change stream enhancements improve real-time data synchronization capabilities.
  • Higher MongoDB compatibility simplifies migration without code changes.
  • Version 8.0.2 supports correlated $lookup for complex join operations.
CHECKLISTWhat matters hereRetryable writes auto-retry transient errors, reducing manual error…New aggregation stages enable window functions, faceted search, and…Change stream enhancements improve real-time data synchronization…Higher MongoDB compatibility simplifies migration without code…Version 8.0.2 supports correlated $lookup for complex join operations.

Percona highlights how high-volume write workloads in PostgreSQL can trigger excessive autovacuum cycles and table bloat, leading to severe performance degradation. To mitigate this, the article introduces PgQ and PgQue as workflow engines designed to decouple and manage these frequent updates more efficiently. These tools help stabilize the database by handling write spikes that would otherwise overwhelm standard vacuum processes.

  • High-frequency writes cause excessive autovacuum runs and table bloat in PostgreSQL.
  • PgQ and PgQue serve as workflow engines to manage these heavy update loads.
  • Decoupling updates improves concurrency and prevents unmanageable database states.
  • These tools are relevant for production environments with millions of daily updates.
  • Consider these engines if standard autovacuum cannot keep up with write volume.
HOW IT WORKSDecoupling High-Frequency Writes1High-volume writes occur2PgQ queues the updates3Background workers process them4Autovacuum stabilizes the table
↑