PostgreSQL 19 Is Almost Here — and It Cut Its Biggest Headlines

PostgreSQL 19 is nearly ready. The first release candidate landed on October 15, general availability is planned for November 19, and a second candidate follows on November 12. Normally that's routine. What makes this release worth watching is what the team chose to pull along the way.

Because for once, the headline features didn't make the cut. SQL property graph queries, partition merging and splitting, and the ability to turn data checksums on and off at runtime were all yanked during beta — joined, by most accounts, by GROUP BY ALL and UPDATE/DELETE ... FOR PORTION OF. Altogether, roughly eight to ten features were reverted. The stated reasoning is blunt: reliability comes first, alongside a commitment to a predictable release schedule. Some features simply needed more time than one cycle allowed.

What's left is more boring, and more useful.

Meet REPACK. It's the unified successor to VACUUM FULL and CLUSTER, and its CONCURRENTLY option reclaims disk space and reorganizes rows without blocking reads and writes for most of the job. That's a real win for busy, update-heavy tables. The catch, as with anything in Postgres, is stated honestly: the final table-and-index swap still needs an ACCESS EXCLUSIVE lock, and the operation needs temporary disk space. Nothing is ever fully lock-free, and the docs say so.

There's also pg_plan_advice, built by Robert Haas, which finally gives you a lever on the query planner. Through EXPLAIN (PLAN_ADVICE) you can pin down join order and scan methods, then apply that guidance automatically per query ID with the companion pg_stash_advice extension. If you've ever shipped a change only to watch a plan regress in production, this one is aimed straight at you.

Autovacuum gets a long-overdue boost too: parallel workers for index vacuuming, plus a scoring system that prioritizes the work, visible through the new pg_stat_autovacuum_scores view.

And for anyone eyeballing a database migration: logical replication of sequence values. When you create a subscription, sequences can sync from publisher to subscriber, and ALTER SUBSCRIPTION ... REFRESH SEQUENCES re-syncs them later. Two caveats the docs are careful to spell out: the publisher must be running 19 or newer, and this is not continuous synchronization, so your cutover planning still matters.

Two smaller gems round it out. Setting wal_level to replica lets you enable logical replication without a server restart, and a new WAIT command gives standby reads read-your-writes consistency by waiting until a given log position is replayed.

The schedule itself tells the same story as the reverts. The release is about a month later than originally planned, because the point release due on November 12 carries a large number of fixes the team wanted folded into 19 before GA. Ship fewer headline features, ship them solid.

If you run Postgres in production, there's a worthwhile test this week: grab RC1 and run your real monitoring queries against it. One developer who tested RC1 across 1,208 scenarios found two queries that needed rewriting after a single server-side change. As always, the migration work lives in the boring details — which is exactly where this release invested its effort. ```