OffNet Newsroom

Daily topic roundup

Database Technology

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

Planet PostgreSQL database

PostgreSQL Standby Delays: Lag Budget vs Query Cancellation

Christophe Pettus clarifies that max_standby_streaming_delay and max_standby_archive_delay control replication lag, not query execution time. Once the allocated delay budget is exhausted, standby queries are canceled immediately, regardless of their duration. This distinction is critical for tuning read replicas to handle heavy analytical workloads without unnecessary aborts.

  • These GUCs manage replication lag, not query runtime on the standby.
  • Queries are canceled immediately once the delay budget is exceeded.
  • Long-running analytical queries on standbys are vulnerable to cancellation.
  • Tune these parameters based on acceptable replication lag, not query length.
Planet PostgreSQL database

Interleaved Backfills Spike WAL and Heap Size in PostgreSQL

TypeSafe’s migration to store AI-generated labels in PostgreSQL revealed that interleaved batch updates caused significant bloat. Range-based batching at default fillfactor nearly doubled heap size and index weight, while higher fillfactor with frequent VACUUM reduced heap growth but still increased index size. Only 11.5% of updates were HOT, indicating heavy index maintenance overhead during the backfill process.

  • Interleaved batch updates cause disproportionate WAL generation and heap bloat in PostgreSQL.
  • Range-based backfills at default fillfactor significantly increase both heap and index sizes.
  • Increasing fillfactor and running VACUUM between batches reduces heap bloat but not index growth.
  • Low HOT update rates indicate heavy index maintenance costs during large-scale backfills.
  • Monitor index size growth when planning large table migrations or label storage updates.
BY THE NUMBERSLow HOT Update Rate11.5%Updates were HOTIndicates heavy index maintenance overhead

Dmitry Narizhnykh introduces a free PostgreSQL Dump Viewer that allows users to inspect backup files without restoring them to a live server. The tool replays the dump into a virtual PostgreSQL instance within the browser tab, enabling read-only SQL queries and schema inspection. This approach keeps the dump file local and avoids the overhead of provisioning a temporary database server for verification.

  • Avoids full restore overhead by replaying dumps in a browser-based virtual instance.
  • Enables read-only SQL execution for quick schema and row verification.
  • Keeps sensitive dump files local; no data is uploaded to external servers.
  • Useful for validating backup contents before committing to a full restore process.
PostgreSQL News database ↺ since 09-24

PgBouncer 1.26.0 Fixes Three CVEs and Adds Meson Build Support

PgBouncer 1.26.0 addresses three critical denial-of-service vulnerabilities, including crashes from malformed SCRAM messages and infinite loops from integer overflows. The release introduces new configuration options like pool_idle_timeout and per-user query_wait_timeout, while also tracking search_path and transaction read-only settings by default. Additionally, it adopts Meson for building and removes the deprecated online restart functionality.

  • Patch immediately to prevent DoS from unauthenticated clients exploiting SCRAM or buffer logic flaws.
  • Update build pipelines to support Meson, as legacy build methods are being phased out.
  • Leverage new pool_idle_timeout and granular query_wait_timeout for better resource control.
  • Verify that search_path and default_transaction_read_only tracking aligns with current app expectations.
CHECKLISTPgBouncer 1.26.0 Patch ChecklistPatch immediately to prevent DoS attacksUpdate build pipelines to support MesonLeverage new pool_idle_timeout settingsVerify search_path tracking alignment
AWS What's New awsdatabase ↺ since 09-25

Amazon RDS for PostgreSQL now supports PostgreSQL 19 Beta 4

Amazon RDS for PostgreSQL 19 Beta 4 is now available in the Database Preview Environment for evaluation. This release refines query performance and autovacuum management introduced in earlier betas, alongside stability improvements. Key fixes address pg_stat_autovacuum_scores reporting for TOAST tables and correct freeze-score scaling for better tuning.

  • Preview environment allows early testing of PostgreSQL 19 Beta 4 features on RDS.
  • Autovacuum parallel workers now share a rebalanced cost limit to respect configured limits.
  • Fixed pg_stat_autovacuum_scores view to properly report on TOAST tables.
  • Corrected freeze-score scaling enables more effective autovacuum prioritization tuning.
  • Refer to community announcement for full technical details on this beta release.
CHECKLISTWhat matters herePreview environment allows early testing of PostgreSQL 19 Beta 4…Autovacuum parallel workers now share a rebalanced cost limit to…Fixed pg_stat_autovacuum_scores view to properly report on TOAST…Corrected freeze-score scaling enables more effective autovacuum…Refer to community announcement for full technical details on this…
AWS Database Blog awsdatabase ↺ since 09-26

Stream PostgreSQL CDC to S3 via Fargate with private networking

AWS demonstrates a fully managed, event-driven CDC pipeline that streams row-level changes from RDS for PostgreSQL or Aurora PostgreSQL to Amazon S3 in near real time. The solution is deployed using a single CloudFormation template and operates within private subnets, ensuring no internet gateway exposure. This architecture enables secure, low-latency data ingestion for analytics or archival purposes without public internet access.

  • Deploy full CDC pipeline via single CloudFormation template for rapid provisioning
  • Supports both RDS for PostgreSQL and Amazon Aurora PostgreSQL sources
  • Operates in private subnets with no internet gateway for enhanced security
  • Streams row-level changes to S3 in near real time for downstream consumption
AWS Database Blog awsdatabase ↺ since 09-24

FireTV cuts DynamoDB write costs 97% with vertical partitioning

Amazon FireTV redesigned its watch-progress data model in DynamoDB by applying vertical partitioning and hash-prefixed sort keys to enable parallel reads. This architecture removes item-size limits and allows the system to serve millions of customers with read latencies under 50 milliseconds regardless of profile size. The approach resulted in a 97% reduction in write costs while maintaining high performance.

  • Vertical partitioning eliminates DynamoDB's 400KB item size limit for large datasets
  • Hash-prefixed sort keys enable efficient parallel read execution across partitions
  • Write costs dropped 97% by optimizing data structure and query patterns
  • Read latency remains under 50ms at scale without sacrificing throughput
Planet PostgreSQL database ↺ since 09-26

Use max_slot_wal_keep_size to prevent replication slot disk exhaustion

Setting the GUC max_slot_wal_keep_size allows PostgreSQL to automatically terminate replication slots that exceed a specified WAL size threshold. This prevents stalled replicas from silently consuming all available disk space and crashing the primary server. It serves as a safety mechanism to enforce WAL retention limits without manual intervention.

  • Prevents primary disk exhaustion caused by stalled replication slots
  • Automatically kills replicas exceeding the configured WAL retention limit
  • Configurable via the max_slot_wal_keep_size GUC parameter
  • Mitigates risk of server crashes due to full disk scenarios
↑