PostgreSQL 19 is late, and Robert Haas blames LLM bug-finding: back-patched fixes up 61% in a year

PostgreSQL 19 will miss the project's usual release window, and one of its longtime committers says the reason is that language models have become very good at finding bugs in PostgreSQL. Robert Haas wrote on October 30, in a post first published on Neon's blog, that version 19 "most likely won't be released until November," and that "it's not impossible that the project could decide to postpone the release further." For about a decade, major releases have landed between mid-September and mid-October.

His title is "Postgres 19 is late, and it's AI's fault", and the argument behind it is more specific than the joke. The bugs are not new. What changed is that "it's become vastly easier to find those bugs. Fixing them has also gotten easier, but not to the same degree."

The numbers

Haas compares the same window in two years: from feature freeze on April 8 to September 25.

The interesting line is the one Haas mentions only in passing. Subtract the back-patched commits from master and what is left, new work on master alone, comes to 313 in 2025 and 274 in 2026: a slight decline, as he says. So the extra volume is almost all fixes, not features. And the jump on the previous stable branch is the strongest evidence for his point, because those fixes go into code that has already shipped. Those are not mistakes from this year's rush. Haas puts the cause bluntly: "a huge number of people on the Internet are now reporting bugs in PostgreSQL that they found using LLMs, and the PostgreSQL committers have been very, very busy fixing them."

He does allow that some of the growth could be committers making more mistakes, but says "I don't think anyone who works on the project really believes that's the main cause." The post gives no count of how many reports came from LLM-assisted hunting, so that link is his reading of the project, not a measured figure.

Three features pulled late

The other unusual thing about this cycle is what got cut. Three large features were reverted between August 27 and September 15, well into beta. The commits on GitHub show how much had piled up on top of each:

• ALTER TABLE … MERGE/SPLIT PARTITION, reverted on August 27 by Alexander Korotkov together with a dozen follow-up fixes, "due to multiple design issues which are too late to address in this release cycle" (commit).
• SQL Property Graph Queries (SQL/PGQ), reverted on September 7 by Peter Eisentraut: the feature commit plus 48 later commits, many of them fixes, including one for a segfault from cross-variable references in graph patterns (commit).
• UPDATE/DELETE FOR PORTION OF, reverted on September 15, also by Eisentraut: the feature plus 22 follow-ups, with names like "Fix RLS checks for FOR PORTION OF leftover rows" and "Fix assertion failures in DELETE FOR PORTION OF tuple routing" (commit).

The revert messages themselves don't mention LLMs, and Haas doesn't claim that machine-found bugs killed these features directly. His explanation is about attention. LLMs "can draft fixes, but those fixes aren't always correct or compliant with PostgreSQL standards," so humans still review and commit every one, "and those humans have not gotten any smarter between 2025 and 2026." Time that would have gone into deciding what was ready for 19 went into security issues and back-branch bugs instead, and the decision to pull features came later than usual.

Finding is cheap, verifying isn't

That asymmetry is the part that applies well beyond PostgreSQL. Discovery now scales with the number of people pointing a model at a code base. Review scales with the number of committers, and PostgreSQL's is a small, careful group. On Hacker News, where the post has drawn more than a hundred comments, the top reply makes the same point: discovery isn't the bottleneck anymore, verification is. Others pushed back that a slightly late release in exchange for fixing long-hidden bugs is a good trade, which Haas more or less agrees with: he calls the delay not "particularly concerning," since it "emerges directly from the project's concern for quality."

What worries him is the longer run. "Given that we have forty years of bugs that humans were unable to find but LLMs are quite capable of discovering, how are we ever going to catch up, and how will PostgreSQL continue to innovate? Right now, I'm not sure."

It is the mirror image of a story from the same week. Kyle Kingsbury's Jepsen report on ParticleDB looked at a database built quickly with LLM help and found 96 bugs and fixes that weren't. PostgreSQL is the opposite case: decades of careful human code, now being audited by machines faster than its maintainers can respond. Haas's conclusion is that every feature from here on "will be scrutinized by AI, and things that would have escaped forever unnoticed in an earlier era will now be found, perhaps in a matter of hours."

No new release date for PostgreSQL 19 has been announced yet.