Postgres 19: What Changed and What to Test Now

With the first release candidate available, PostgreSQL 19 brings practical advances in database maintenance, query planning, and replication.Reclaiming disk space on a busy table. Understanding why a query’s execution plan changed. Keeping maintenance ahead of a growing workload. Making sure sequence values are ready when an application moves to a subscriber.These are the kinds of operational problems PostgreSQL 19 addresses. Its current feature set includes concurrent table repacking, query plan advice, improvements to autovacuum, and sequence synchronization for logical replication. It also adds ON CONFLICT DO SELECT, so upserts can return existing rows, and IGNORE NULLS in window functions. For teams running Postgres®, there is plenty worth evaluating beyond the features that generated the earliest headlines. The first release candidate arrived on October 15. The community now plans a second release candidate for November 12 and general availability for November 19, subject to any issues requiring further changes. The additional time will allow fixes from the November maintenance release to be incorporated before PostgreSQL 19 becomes generally available. That makes this a good moment to reset expectations: Understand what changed, look closely at the capabilities moving toward release, and test them against the work your database actually does. If you run Postgres in production today, PostgreSQL 18 remains your production target until 19 reaches general availability. Test 19 in non-production now, so you are ready.What changed, and what to learn from it As described in the PostgreSQL 19 Beta 4 release notes, a significant number of major features were reverted from previous Beta releases. They include SQL property graph queries, partition merging and splitting, and the ability to enable or disable data checksums while the server is running. Others reported in the community’s tracking include& GROUP BY ALL and UPDATE/DELETE ... FOR PORTION OF. The community’s explanation is explicit: Reliability comes first, alongside a commitment to a predictable release schedule. Some features needed more development and review than this cycle could accommodate. It would be too simple, however, to treat every reversion as either a failure or an unqualified success. In his recent reflection, EnterpriseDB’s (EDB’s) Peter Eisentraut describes several overlapping pressures: architectural problems in some features, AI-assisted review uncovering more edge cases, and senior …