PostgreSQL has shipped a new major version every autumn for years, and PostgreSQL 19 will not make the date people expected. The fourth beta is due on Thursday 24 September, and the project has reverted 53 changes during the beta cycle, including the release's biggest headline feature, graph queries. For teams that plan upgrades around the usual calendar, the question is no longer which features to test but which ones will actually be there.
Here is what has been pulled, why, what still ships, and when PostgreSQL 19 is now likely to land.
Why PostgreSQL 19 Is Behind Schedule
In a post for the Snowflake engineering blog, Elizabeth Garrett Christensen writes that the code is in a heavy review cycle, that major features have been reverted during beta and that many others are under heavy revision. Her assessment is that the release is certainly delayed by weeks and maybe even months. The project's priorities, she writes, were quality first and shipping within the usual window second, and the team is reducing the scope of the release to get closer to its timeline.
There is no announced general availability date. According to Layerbase, which tracks the schedule, Beta 4 on 24 September is the only dated milestone, and the Release Management Team has said its goal is general availability by the end of October, which would keep the release inside the usual September to October window. That is a stated goal, not an announcement, and Layerbase notes that the project's own PostgreSQL 19 open items page still lists the first release candidate and the final release as to be decided.
The Biggest Cut Was Graph Queries
SQL Property Graph Queries, known as SQL/PGQ, became part of the SQL standard in 2023. They let you declare a property graph over existing tables and pattern-match across it with GRAPH_TABLE, a lighter way to ask graph questions without adopting a separate graph database. It was the largest feature in PostgreSQL 19, and it is out.
Layerbase reports that the revert on 7 September removed around 16,000 lines across 124 files. The reasons were readiness and design rather than a single bug. The Register quoted longtime contributor Tom Lane on the decision: "At this point I'd be willing to bet dinner that if we ship it in v19 there will be post-release bug discoveries that are unfixable until v20." Tom Kincaid, senior vice president of software engineering at EDB, confirmed to the publication that the feature will not be part of PostgreSQL 19.
The work is not abandoned. Snowflake's post describes property graphs as PostgreSQL 20 material, though Layerbase cautions that a feature of that size restarting after a revert is not a safe bet for version 20 either.
The Other Features That Were Pulled
Graph queries were the headline, but the list is long. Layerbase dates the most visible reverts from the project's commit log:
- ALTER TABLE MERGE/SPLIT PARTITION(S), a long-requested way to reshape partitions, reverted on 26 August with a commit message citing multiple design issues too late to address in this cycle.
- UPDATE/DELETE FOR PORTION OF, temporal updates that split a row across its validity period, reverted on 15 September after the revert had to unwind 23 commits.
- GROUP BY ALL, shorthand for grouping by every non-aggregated column, reverted on 17 July after post-commit review found it could produce wrong results with some ORDER BY entries.
- Non-text output formats for pg_dumpall, which would have made whole-cluster dumps restorable in parallel, reverted on 18 June.
Snowflake's list adds JSON_TABLE ON ERROR cascading, a fast default for domains with nonvolatile constraints, and nested query tracking in pg_stat_statements. The common thread, according to the post, is design flaws found in post-commit review, wrong results, or compatibility concerns discovered late, and most of these features will be tried again for version 20. The GROUP BY ALL commit message says as much, and Layerbase rates it the most likely to return.
One item is disputed. Snowflake's list includes the change of the default TOAST compression to lz4, but Layerbase says it found no such revert in the commit log and that the current documentation still gives lz4 as the default where the build supports it. Check the setting on your own server rather than relying on either write-up.
How 53 Reverts Compares With Past Releases
Reverts are a normal part of how PostgreSQL gets made. Patches arrive through open commitfests, are discussed on the hackers mailing list and are committed by one of roughly 30 committers, then a beta is cut and tested before the final release and its quarterly maintenance updates, as the Snowflake post lays out.
What stands out this year is timing rather than volume. PostgreSQL 18 had about 44 reverts, according to Snowflake, most of them shortly after its beta began. PostgreSQL 19 has 53 so far, and many arrived late and hit headline features. Christensen notes that delaying a major release is something that has not happened with PostgreSQL in a long time, and argues that the process is working as designed: features that are not ready are pulled, and the reasoning is public.
The AI Factor in the Review Cycle
The Snowflake post puts part of the explanation down to AI. Several contributors are using AI tools to find bugs and build reproducible test cases, and many of the late reverts came from in-depth AI-generated reviews. Robert Haas, one of the project's major contributors, ran a bug contest with AI assistance that surfaced more features at risk.
The effect is visible in security work too. PostgreSQL used to average a couple of CVEs per release, the post says, while the August 2026 patch for PostgreSQL 18 fixed 28. The project has no official AI contribution policy yet, though one is expected soon.
AI is now on both sides of infrastructure code. Our report on how Bun's Rust rewrite took 11 days and cost $165,000 looked at agents writing a runtime at speed. PostgreSQL 19 shows the other side: AI-assisted review slowing a release down because it found problems people had missed.
What Still Ships in PostgreSQL 19
The release is still substantial. The feature most likely to matter to operators is REPACK, which does what VACUUM FULL and CLUSTER did, plus a CONCURRENTLY option. As The Register explains, VACUUM FULL holds an exclusive lock for the whole rewrite, blocking reads and writes, while REPACK CONCURRENTLY lets other transactions use the table for most of the operation and only needs the exclusive lock briefly when the new files are swapped in. The open items page still lists several REPACK (CONCURRENTLY) issues being worked on, so test it carefully.
Layerbase and Snowflake also list pg_plan_advice for stabilising planner decisions, parallel autovacuum, ON CONFLICT DO SELECT so that upserts return the existing row, IGNORE NULLS and RESPECT NULLS on window functions, JSON output from COPY TO, a new WAIT command for read-your-writes against a replica, and an EXCEPT clause for publications. Two behaviour changes deserve attention before upgrading: JIT now defaults to off, and default_toast_compression defaults to lz4 where the build supports it.
What Builders Should Do Now
The practical advice is to test against the beta rather than wait. Layerbase notes that beta data directories are not guaranteed to carry forward between betas or into the final release, so moving between them means a dump and restore rather than an in-place upgrade.
Watch the open items page and the hackers mailing list, because more features could still be pulled. And if you were planning around graph queries, partition merge and split or GROUP BY ALL, plan for PostgreSQL 20 instead. For everyone else, PostgreSQL 19 remains a meaningful upgrade, just later than the calendar suggested.
