OffNet Newsroom

Daily topic roundup

Database Technology

Wednesday, October 14, 2026 · 8 stories, curated & summarized — click any story for the source.

PostgreSQL Releases databasereleases

PostgreSQL 19 Release Candidate 1 (REL_19_RC1) Published

The PostgreSQL global development group has released REL_19_RC1, marking the first release candidate for version 19. This build serves as the final candidate before the stable release, indicating that core functionality is feature-complete and entering the stabilization phase. It is available for download via the official GitHub releases page.

  • RC1 signals feature freeze; only critical bug fixes are expected before final release.
  • Downloadable directly from the official PostgreSQL GitHub releases repository.
  • Suitable for testing major upgrade paths and verifying compatibility with new features.
  • Scheduled for publication on 2026-10-12.

Christophe Pettus discusses using the post_auth_delay and pre_auth_delay GUCs to pause backend execution during connection establishment. These settings allow engineers to inspect the process state before or after authentication completes, which is critical for debugging complex connection issues. The approach provides a controlled way to analyze backend behavior without relying on external tracing tools.

  • Use post_auth_delay to pause execution after successful authentication for state inspection.
  • Use pre_auth_delay to pause execution before authentication begins for early debugging.
  • These GUCs enable targeted backend analysis without modifying application code.
  • Useful for diagnosing hang-ups or resource contention during connection setup.
  • Consultant-tested technique for deep-dive PostgreSQL connection troubleshooting.
Planet PostgreSQL database

Zero-downtime Postgres upgrades via logical replication

This article details a zero-downtime strategy for major Postgres version upgrades using logical replication, covering versions 10 through 19 beta. It positions this approach as the most common use case for the feature, enabling seamless transitions between releases. The method also provides a safety mechanism to revert if the upgrade process fails unexpectedly.

  • Logical replication enables major version upgrades without service interruption.
  • Supports Postgres versions 10 through the upcoming 19 beta release.
  • Provides a reliable rollback path if the upgrade encounter issues.
  • Builds on prior hub-and-workers and consolidation architectures.
TRADE-OFFLogical Replication UpgradeStandard UpgradeRequires service downtimeRisk of data lossDifficult rollback pathLogical ReplicationZero downtime guaranteedSafe continuous replicationReliable rollback optionvs

Hollis Varden tested row deletion on a 2,000,000-row PostgreSQL 18.6 table and found that standard VACUUM does not reduce on-disk size. Deleting half the rows left the table at 137 MB, and running VACUUM kept it at 137 MB. Only VACUUM FULL reclaimed space, shrinking the table to 68 MB.

  • Standard VACUUM reclaims tuples for reuse but does not shrink the physical file size.
  • DELETE operations mark rows as dead; VACUUM cleans them up without truncating the table.
  • VACUUM FULL is required to physically reduce the table size on disk.
  • VACUUM FULL is significantly slower and requires an exclusive lock on the table.
THE SHIFTSpace Saved by VACUUM FULL137MBPOST DELETE SIZE68MBPOST VACUUM FULLOnly VACUUM FULL shrinks on-disk file

A new analysis benchmarks Liquid Clustering against traditional ZOrdering and partitioning strategies across four distinct workload types in Delta Lake. The author identifies two undocumented failure modes that currently impact production systems using these layout techniques. The article provides a decision framework to help engineers select the most appropriate physical data layout strategy for their specific use cases.

  • Liquid Clustering offers alternatives to static partitioning and ZOrdering for optimizing data layout.
  • Two undocumented failure modes exist that may affect current production Delta Lake deployments.
  • Performance varies significantly by workload type; no single layout strategy fits all scenarios.
  • Use the provided decision framework to match layout strategies to specific query patterns.
AWS What's New awsdatabase

Amazon RDS for SQL Server adds support for CU8 (KB5104822)

Amazon RDS has enabled the latest Cumulative Update for Microsoft SQL Server, specifically version 2025 CU8 (KB5104822). This update is available as RDS version 17.00.4075.5.v1 and includes various improvements and fixes detailed in Microsoft's documentation. Database administrators can apply these changes to their instances via the RDS Management Console, AWS CLI, or SDK.

  • RDS now supports SQL Server 2025 CU8 (KB5104822) for immediate patching.
  • Upgrade is available via Console, CLI, or SDK for existing instances.
  • Check Microsoft KB5104822 for specific fixes and improvements included.
  • No manual OS-level patching required; managed via RDS engine version update.
HOW IT WORKSApplying the SQL Server CU8 Update1Identify instance needing update2Select engine version 17.00.4075.5.v13Apply via Console, CLI, or SDK4Verify KB5104822 fixes are active

Ming Ying details how ParadeDB accelerates COUNT queries on Wikipedia data by implementing ctid-aware segment partitioning and an inverted DocId map with bitmap postings. The approach extends to broader search workloads, where the system achieved 10 to 22 times higher throughput than TIN for filtered and time-sorted Hacker News queries. This optimization strategy highlights specific internal mechanisms for scaling search performance within PostgreSQL.

  • ctid-aware segment partitioning reduces I/O for COUNT operations on large datasets
  • Inverted DocId maps with bitmap postings significantly speed up search filtering
  • ParadeDB delivers 10-22x throughput gains over TIN for time-sorted queries
  • Optimizations target specific search patterns rather than general table scans

Chris van Eijk benchmarks custom session settings in PostgreSQL 17, analyzing how NULL or empty string values are handled by current_setting and set_config. The analysis covers value persistence, default behaviors, and permission models for who can modify these configurations. This measurement clarifies edge cases in session-level parameter management.

  • Clarifies NULL vs empty string handling in custom session settings
  • Measures persistence duration of set_config values within sessions
  • Details permission requirements for modifying configuration parameters
  • Provides empirical data for PostgreSQL 17 session management
↑