Postgres 19 slips to November after LLM code review surfaces too many bugs to fix in time

A bar raised after the code was written

The Register reports that the PostgreSQL Global Development Group has pushed the PostgreSQL 19 release to around November 19 and dropped between eight and ten significant features, which now target PostgreSQL 20. Peter Eisentraut, a leading committer and VP at EDB, said in a blog post that LLM-assisted review is at least partly to blame: some reverted features had serious architectural defects that were hard to fix during beta, and review also surfaced many minor issues. The quality bar rose after the features had been written and committed, and he stressed the reverts were not caused by "vibe coding," since the technique was not available when most of the features were written.

The most visible casualty is SQL/PGQ, the SQL property graph query feature; Tom Lane had warned that shipping it in 19 would produce bugs unfixable until 20. REPACK CONCURRENTLY stays in, and Eisentraut called 19 "a great release" that will be "very robust."

The people who test Postgres say the gaps were already there

The most informative voice was the co-creator of pgrust, a Rust rewrite of Postgres, who previously ran Freshpaint and led the database team at Heap, because they have been hunting for these bugs from outside the project:

"If I had to root cause why we're finding so many bugs now, I would attribute it to the limited Postgres test suite. AI is merely uncovering bugs that already existed."

They say they have found about 50 bugs in core Postgres, not by asking a model to review code but by using one to build deterministic simulation testing, differential fuzzing and formal proofs. Skeptics pushed the other way. An engineer who ran a review agent and a coding agent against each other this summer hit a loop: "the review agent would find bugs, the coding agent would fix them in some overengineered way that introduced new bugs… repeat until insanity. Not every time. But often enough."

Both point to the same cost: a model that flags defects is cheap, but triage and fixes are not. If you maintain a database or compiler, budget review capacity before you switch on AI review, and spend the model on systematic test generation first.