What happened

PostgreSQL 19 will not ship when it was supposed to. The release was slated for late September or early October 2026. The project now says it should be made generally available on November 19, 2026, "unless an issue is discovered that requires a delay or an additional release candidate." The first release candidate, RC 1, went out on October 15. A second, RC 2, is planned for November 12.

Image: daamien via Wikimedia Commons, CC BY-SA 3.0 DE.

The reason is what makes this news. According to Peter Eisentraut, a long-time PostgreSQL committer, LLM-assisted code review found defects in new features faster than the project's developers could fix them, and the release team pulled roughly 8 to 10 significant features rather than ship them half-repaired. The Register reported the delay on October 16.

AI review is usually sold as a way to ship faster. Here it did the opposite.

Why AI review slowed the release down

Eisentraut laid out the mechanics in an October 9 post titled "The reverts will continue until morale improves." PostgreSQL's design promise is that features compose. "I like to say, in PostgreSQL, 'everything works with everything'," he writes, and users expect the strange combinations to work. A new feature has to behave alongside partitioning, triggers, replication and everything else, and nobody can enumerate those combinations by hand, let alone test them all.

An LLM reviewer can generate them. "With LLM-assisted code review, these kinds of things can get found much faster, and then you're staring at a list of like forty defect reports," Eisentraut writes. Most are what The Register summarises as "relatively harmless issues involving various edge cases." One by one they are cheap. Together they are not: "Even if each of them requires only a three-line fix on average, there is a fixed overhead to dealing with each of these, and then you run out of time."

Each report still needs a human to reproduce it, judge it, write the fix, get that fix reviewed and commit it. The cost of finding a bug fell. The cost of closing one did not.

AI was not the only factor. Eisentraut says the "Vulnpocalypse" kept many senior developers busy with security fixes from roughly April to August, the stretch when beta review and testing would normally happen. Less human capacity met a much longer defect list. For some of the reverted features the reports also exposed architectural defects that would have been hard to fix "quickly and during beta."

The PostgreSQL 19 Open Items wiki shows the scale: more than 180 items resolved between beta 1 and the release candidates, with a handful still open when we checked on October 19, 2026.

What was pulled from PostgreSQL 19

The most visible casualty is SQL Property Graph Queries (SQL/PGQ), the graph query syntax that entered the SQL standard in 2023 and was coming to PostgreSQL through the GRAPH_TABLE clause. Tom Lane, one of the project's longest-serving contributors, had argued against shipping it back in September: "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." It does not appear in the 19 release notes.

Image: Nevit Dilmen via Wikimedia Commons, CC BY-SA 3.0.

The Open Items wiki records other reverts alongside it, including the offline data checksum changes, leftover pieces of the temporal FOR PORTION OF work, MERGE PARTITIONS and SPLIT PARTITIONS, the pg_get_*_ddl() functions (sent back for a redesign) and non-plain output formats for pg_dumpall. Treat that as a sample from the wiki rather than an official list. Eisentraut's own count is "about" 8 to 10 significant features.

What is still in PostgreSQL 19

"PostgreSQL 19 will still be a great release," Eisentraut writes, "and it will be very robust, after all the additional scrutiny." The release notes back him up for anyone who runs Postgres in production.

Image: Kelti via Wikimedia Commons, CC BY-SA 4.0.

The headline is REPACK, a new command that reclaims disk space and reorganises tables. REPACK (CONCURRENTLY) does it without blocking reads or writes, the job many teams hand to the pg_repack extension today. It survived the cull, though RC 1 still carries several fixes for it.

Replication loses two operational chores. Logical replication can now be switched on without a server restart when wal_level is set to replica, and sequence values replicate logically, so a logical-replication cutover no longer ends with a manual sequence resync. A new WAIT command gives read-your-writes consistency on standbys.

Planner control arrives through the pg_plan_advice extension, with pg_stash_advice to apply that advice automatically. Autovacuum can process a table's indexes in parallel and decides what to vacuum first with a new scoring system. I/O worker processes scale automatically, and foreign-key checks are quicker.

One behaviour change landed in RC 1 itself: COPY (query) TO ... (FORMAT json) now uses the query's column names, aliases included, as the JSON keys. If you tested JSON output from COPY on a beta, test it again.

What it means for your upgrade plan

Teams that pencilled in an October upgrade should push it back about seven weeks. Test against RC 1 now. Retest on RC 2 on November 12, which lands the same day as the update release for supported branches; the release team is folding that release's large batch of fixes into 19 before GA. Schedule production for after November 19, and only once that date actually holds. Coming from any earlier major version still means pg_upgrade or pg_dump and pg_restore, as the RC 1 announcement notes.

Image: PgAdmin Ueberblick via Wikimedia Commons.

If you were waiting for SQL/PGQ to retire a separate graph database, keep the graph database. The reverted features now aim at PostgreSQL 20, which has no date. Eisentraut says it is hard to predict, and a few months ago he suggested 20 "might have no new features, just bug fixes." It now has a backlog of returning features to absorb, every one of which will meet the same LLM-assisted review.

That is the lesson for anyone shipping software with AI reviewers in the loop. The edge cases in PostgreSQL 19 existed before; the difference is that someone could now list them in an afternoon. The bottleneck moved from finding bugs to fixing them, and a project that runs on contributors' limited time felt it first.