Postgres Weekly — 2026-05, Week 20
Editor’s Note
Two upcoming Postgres releases are drawing attention this week for different reasons: PostgreSQL 18 addresses a well-documented operational frustration with large-table vacuuming, while PostgreSQL 19 quietly removes a failure mode that has caused production outages on high-concurrency clusters. Alongside those internals stories, the lakehouse integration space is generating architectural debate, and the question of how to fairly benchmark hosted Postgres services is getting a more structured answer.
Top Stories
PostgreSQL 18 Caps Dead-Tuple Accumulation with autovacuum_vacuum_max_threshold
The existing autovacuum trigger model, which relies solely on autovacuum_vacuum_scale_factor, has long been a pain point for operators managing tables in the hundreds of millions of rows — under the scale-factor formula, a billion-row table could accumulate roughly 200 million dead tuples before a vacuum cycle fires. PostgreSQL 18 introduces autovacuum_vacuum_max_threshold, a new GUC that imposes an absolute upper bound on dead-tuple accumulation independent of table size. For teams running large OLTP schemas, this makes autovacuum behavior more predictable without requiring per-table storage parameter overrides. Read the full breakdown.
PostgreSQL 19 Expands MultiXact Counters to 64 Bits
PostgreSQL 19 widens both MultiXactOffset and MultiXact Members from 32 to 64 bits, closing off a wraparound failure mode that has caused unplanned downtime on clusters under sustained concurrent-write pressure — particularly those with foreign key constraints that generate heavy multi-transaction activity. The 32-bit ceiling on these counters is less widely understood than transaction ID wraparound, but the operational consequences are comparable: a cluster that exhausts the counter space enters a state requiring manual intervention. Removing that ceiling is a meaningful reliability improvement for high-concurrency deployments. Full technical context here, and a deeper dive into the Members counter specifically is also available.
pg_lake and Lakebase: Postgres Branding, Opposite Architectures
Snowflake’s pg_lake and Databricks’ Lakebase both present PostgreSQL-compatible interfaces for lakehouse workloads, but an architectural comparison finds they take nearly inverse approaches to compute-storage coupling and query execution. The surface-level similarity — both use the Postgres wire protocol — can obscure meaningful differences in how queries are planned and executed, and in what consistency and performance guarantees are actually provided. For architects evaluating either product, understanding what lies beneath the Postgres compatibility layer matters considerably more than the shared branding. The comparison is worth reading in full.
Figma’s pgKeeper and the Limits of Off-the-Shelf Connection Pooling
Figma has published an account of building pgKeeper, an internal connection proxy derived from PgBouncer but designed to handle traffic spike patterns that generic pooling solutions did not address adequately at their scale. The write-up is a useful case study in where PgBouncer’s operational model reaches its limits and what engineering investment purpose-built traffic management requires. It also reflects a broader pattern: as Postgres deployments grow, the connection layer increasingly becomes a point of custom engineering rather than configuration. Read Figma’s engineering post.
PostgresBench: A Reproducible Framework for Comparing Hosted Postgres
ClickHouse has released PostgresBench, a benchmarking framework designed specifically for reproducible, comparative performance evaluation across hosted Postgres services. The explicit focus on reproducibility is the notable design choice here — prior comparisons of managed Postgres offerings have often lacked standardized methodology, making results difficult to validate or extend. The framework does not resolve every variable in cloud benchmarking, but a shared, inspectable methodology is a reasonable starting point for more credible comparisons. Details on the framework.
Releases
pgEdge Control Plane now includes Supporting Services management alongside a preview of systemd integration for process supervision. The systemd support is currently in preview and targets operators who want tighter lifecycle management within standard Linux service infrastructure. Vendor announcement.
Worth Reading
A Field Guide to Alternative Storage Engines for PostgreSQL — A structured overview of non-heap storage engine options available within the Postgres extension ecosystem.
You Have a Patroni Leader Election — A practical walkthrough of what happens during a Patroni leader election and what operators should watch for.