Database Technology

PostgreSQL 19 will miss its expected fall release window due to a heavy review cycle and the reversion of several major features during beta. The development team is prioritizing quality over the original timeline, resulting in a reduced scope for the upcoming version. Beta 4 is scheduled for September 24, 2026, but the final release is now pushed back by weeks or potentially months.

• Postgres 19 release is delayed beyond the traditional fall window.
• Major features were reverted during beta to ensure code quality.
• Scope reduction is being used to balance timeline and stability.
• Beta 4 targets September 24, 2026, with final release further out.
• Teams should adjust upgrade plans and avoid relying on reverted features.

Percona has extended its Kubernetes operator capabilities by introducing cross-site replication support for Percona Server for MySQL (PS MySQL) in version 1.2.0. This new feature enables the configuration of a Disaster Recovery (DR) cluster that replicates from an existing Data Center (DC) cluster using Group Replication or InnoDB Cluster topologies. The update mirrors similar functionality previously released for the Percona XtraDB Cluster (PXC) operator, providing a consistent approach to multi-site deployments.

• PS MySQL operator v1.2.0 now supports cross-site replication for Group Replication topologies.
• Enables straightforward DR cluster setup replicating from an active DC cluster.
• Aligns MySQL operator features with existing PXC operator cross-site capabilities.
• Simplifies multi-site disaster recovery strategies for Kubernetes-based MySQL deployments.

PostgreSQL 19 REL_19_STABLE received 71 commits between September 8 and 16, 2026. The release window saw six reverts totaling 74 commits, with the latest revert addressing online data checksum transitions by Daniel Gustafsson. Meanwhile, PostgreSQL 20 master branch accumulated 46 commits during the same period.

• PostgreSQL 19 had 71 net commits in the first nine days of the Sept 8-16 window.
• Six reverts removed 74 commits, including critical work on online data checksum transitions.
• Online data checksum transition feature was reverted, likely due to stability or design concerns.
• PostgreSQL 20 master is active with 46 commits, indicating parallel development momentum.
• Two features remain tracked for shipping, suggesting ongoing refinement before final release.

pgAssistant 3.8.0 shifts from a static analysis tool to a continuous improvement platform centered on an Observe-Diagnose-Prioritize-Plan-Implement cycle. The release adds historical workload and environment measurements via pgAssistant Collector to track the full lifecycle of tuning efforts. This enables teams to verify what changes were actually implemented and measure their resulting impact on performance.

• Shifts focus from one-time tuning to a continuous feedback loop for sustained performance gains.
• Historical measurements allow tracking of 'what changed' versus 'what was planned' for accountability.
• Workload Insights now compares consecutive collections to highlight emerging or disappearing trends.
• Integrates with pgAssistant Collector to automate data collection for the improvement cycle.

Percona explains that Percona XtraDB Cluster (PXC) can accumulate thousands of gcache.page.* files when GCache purging is frozen, leading to significant disk space growth. The article details the mechanics behind this accumulation and outlines a safe recovery path using Incremental State Transfer (IST) to rejoin nodes without data loss.

• Frozen GCache purging is the primary cause of excessive gcache.page.* file accumulation in PXC nodes.
• Monitor disk usage closely when nodes are offline or slow, as GCache files will continue to grow.
• Use Incremental State Transfer (IST) for safe node rejoining to avoid full resync overhead.
• Regularly verify GCache size settings to ensure they align with expected network partition durations.

Fleet impact: For PXC clusters, monitor disk usage on data directories for rapid growth of gcache.page.* files, which indicates frozen purging. Ensure IST is viable and configured correctly to allow efficient rejoining of lagging nodes without consuming excessive network or storage resources.

Percona analyzed pgBackRest compression algorithms to identify the optimal balance between CPU overhead and backup size reduction. The findings indicate that Zstandard at low levels provides the best efficiency, with the default zst(3) setting already hitting the practical optimum. Increasing compression levels beyond this point yields diminishing returns on file size while consuming disproportionate CPU resources.

• Zstandard offers the best trade-off between CPU usage and backup size reduction.
• The default zst(3) setting is already near the optimal efficiency point.
• Higher compression levels consume significant CPU for negligible file size gains.
• Review current pgBackRest configs to ensure zst is enabled and levels are not over-tuned.