Postgres Weekly — 2026-04, Week 17
Editor’s Note
This week’s coverage spans a spectrum from kernel-level performance regressions to long-standing debates in query planning finally reaching resolution. Running alongside those stories is a quieter but persistent theme: the continued push to integrate Postgres into broader data architectures, whether lakehouse platforms or workflow execution backends.
Top Stories
Linux 7.0 PREEMPT_NONE Removal Cuts PostgreSQL Throughput by Half
AWS benchmarks reported via thebuild.com show PostgreSQL throughput on Linux 7.0 falling to 0.51x the equivalent workload on Linux 6.x. The regression traces directly to the removal of the PREEMPT_NONE kernel configuration in Linux 7.0, a scheduling mode that historically reduced context-switch overhead for latency-sensitive server workloads. For most production deployments, enabling huge pages is the recommended remediation path, reducing TLB pressure and partially recovering throughput on affected kernels. Teams running Postgres on freshly provisioned Linux 7.0 instances should audit their kernel configuration before attributing performance changes to application or query-level causes. Read more
PostgreSQL 19 to Introduce pg_plan_advice — Hints as Advisory Guidance
Robert Haas’s pg_plan_advice patch, proposed for PostgreSQL 19, brings a resolution to a debate that has persisted for roughly two decades: whether Postgres should support planner hints. The patch frames hints as advisory rather than directive, meaning the planner can consider but is not compelled to follow them — a design that preserves the planner’s cost-model integrity while giving practitioners a sanctioned mechanism for influencing plan selection. The feature is being introduced as a contrib module, reflecting its experimental status, and depesz.com has documented the architectural distinction from conventional hint implementations in other databases. Read more
Postgres in the Lakehouse: Snowflake and Databricks Approaches Now Comparable
With both Snowflake and Databricks having shipped products following last year’s acquisitions, practitioners can now evaluate their respective Postgres-in-the-lakehouse strategies against concrete implementations rather than announced roadmaps. A detailed comparison at thebuild.com examines the architectural trade-offs between the two approaches. Separately, real-time Postgres-to-Iceberg replication via tools such as pg2iceberg is an active area of development for teams seeking to shed the operational overhead of Kafka, Debezium, and Flink pipelines when feeding lakehouse targets. Read more
The Vertical Scaling Ceiling: When a Single Postgres Instance Is Not Enough
pgEdge has published an analysis arguing that vertical scaling, while effective within bounds, cannot indefinitely absorb mixed read/write workload pressure on a single Postgres instance. The piece details the architectural constraints that surface as concurrency, write amplification, and lock contention accumulate beyond what connection pooling and hardware upgrades can address. Multi-master, distributed Postgres deployments are positioned as the next step, though pgEdge acknowledges that active-active replication carries consistency trade-offs that practitioners need to evaluate explicitly before adopting the topology. Read more
Releases
PostgreSQL 19 — REPACK CONCURRENTLY: Álvaro Herrera committed the ADD CONCURRENTLY option to REPACK patch on 6 April 2026, enabling online table repacking without acquiring exclusive locks, which reduces maintenance-window requirements for large tables. Details at depesz.com
pgrx: The current toolchain for building Postgres extensions in Rust remains actively maintained at pgcentralfoundation. Repository
Xata: An open-source, cloud-native Postgres platform has been made available on GitHub. Repository
pg_savior: A new Postgres extension designed to block accidental DELETE and UPDATE statements, operating as a safety interlock at the session or transaction level. Repository
Honker: Implements Postgres-style NOTIFY/LISTEN pub/sub semantics on top of SQLite, extending the event-notification pattern to embedded database environments. Repository
Security and Compliance
Accidental DML Protection — pg_savior: The pg_savior extension intercepts unqualified or unintended DELETE and UPDATE operations before they execute, targeting a recurring class of operator-error data loss in production databases. Teams relying on application-layer safeguards alone may find a database-level interlock a useful additional control. Details