Postgres 19 drops graph queries, GA slips to October

If you penciled a PostgreSQL 19 upgrade into a September maintenance window, move it. The release lost its headline feature two weeks ago, beta 4 is not out until September 24, and general availability has slid toward the end of October. This is the second year running that a Postgres feature list written in June did not survive to ship, and it is worth understanding why before you plan around the next one.

What actually happened

SQL/PGQ — property graph queries — was reverted from the release on September 7. The feature let you define a graph over existing relational tables and query it with GRAPH_TABLE pattern matching, with no new storage engine and no data migration. It was the thing every "what's new in 19" post led with.

The reason was a design hole, not a bug backlog. As The Register reported, PGQ validated its prerequisites at CREATE PROPERTY GRAPH time and then let you drop them — so dropping a primary key or a column could silently break a graph afterward. Tom Lane's assessment in the thread was blunt: ship it in v19 and you get post-release bugs that are unfixable until v20. Tom Kincaid at EDB confirmed the removal, saying the community wanted to work through more issues first. The earliest realistic return is PostgreSQL 20.

It was not the only cut. Christophe Pettus catalogued the cycle: ALTER TABLE MERGE/SPLIT PARTITION reverted in late August, GROUP BY ALL pulled before beta 3, RI fast-path batching removed by its own committer on September 10, plus casefolding and CREATE SCHEMA work. His diagnosis is the schedule — eight major features committed in the five weeks before the April feature freeze, three of them in the final three days.

The current shape: commit freeze September 19, beta 4 on September 24, GA targeted for late October. The postgresql.org roadmap still lists September, which tells you how firm that page is. REPACK CONCURRENTLY did survive, and for most shops that is the actually useful feature — online table rebuilds without the maintenance window.

Why a delayed Postgres release matters for your business

Never schedule a cutover against an unreleased version. The rule we follow: plan the upgrade against the current stable release, and treat the next major as a bonus. A migration window you booked in June against a June feature list is now a window booked against a feature that does not exist.

Read the revert log, not the feature blog. The signal in a .0 release is what got pulled during beta, because that is the community catching problems the marketing round-up cannot see. A project that reverts seven features rather than ship them is behaving correctly. Treat that as a reason to trust it, and a reason to wait for 19.1 anyway.

REPACK CONCURRENTLY is the line item worth planning around. If your bloat maintenance currently means a Sunday night and a locked table, that is a real operational win, and it is the thing to test first when 19 lands.

Sources: The Register, Christophe Pettus, The Build, PostgreSQL roadmap.