"Postgres 19 is late, and it's AI's fault": forty years of hidden bugs are surfacing
Nov 3, 2026Original Robert Haas · Postgres 19 is late, and it's AI's fault ↗
In 3 lines
- AI is finding large numbers of hidden bugs in 40-year-old PostgreSQL, pushing the v19 release to November.
- Stable-branch fixes rose more than 60% for v19 and 74% for v18 year over year, and three features were pulled late.
- Finding bugs got faster but fixing and reviewing remain human work, so every developer has to raise their game.
For a decade PostgreSQL major releases have landed between mid-September and mid-October, but version 19 will likely slip to November. Committer Robert Haas wrote on his blog that the reason is that LLMs happened. Back-patched fixes are up 60 to 74 percent and three features were reverted late in beta. We summarize his argument and the 800-point Hacker News reaction, and what it changes for developers.
Finding bugs in 40-year-old code just got faster
PostgreSQL committer Robert Haas says version 19 will most likely slip to November, and his short answer to why is that LLMs happened. In the past decade major releases landed between mid-September and mid-October. The code base is large, old and has always contained bugs. What changed, he writes, is that finding them has become vastly easier. Fixing them has also gotten easier, but not to the same degree.
By the numbers: back-patched fixes up 60 to 70 percent
From feature freeze (April 8) to September 25, commits to the master branch, where new features go, were about flat year over year. Commits to the in-progress 19 stable branch rose from 724 to 1,169, up more than 60 percent. Commits to the 18 stable branch went from 248 to 433, up more than 74 percent. Haas thinks committers were no more error-prone than usual; more of their usual mistakes were simply caught quickly by LLMs, and many people online now report bugs they found with them.
Three late feature reverts, and human review as the bottleneck
Between August 27 and September 15, three features were pulled late in beta: UPDATE/DELETE FOR PORTION OF, SQL property graph queries, and ALTER TABLE MERGE/SPLIT PARTITION. LLMs can draft fixes, Haas says, but they are not always correct or compliant with PostgreSQL standards, so humans still have to review and commit them, and those humans have not gotten any smarter since 2025. Time that would have gone to reviewing the release went to back-branch security issues and bugs, which delayed decisions on what to revert.
Robert Haas · neon.com ↗The delay is a sign of quality concern, not a crisis
Haas calls the delay short in the grand scheme and says it emerges directly from the project's concern for quality. He adds that the findings do not change his view of the code base: he became a PostgreSQL developer partly because it is some of the cleanest code he has worked on. If it had more defects visible to human eyes, he writes, LLMs would likely have found even more.
The open question: how do you catch up on forty years of bugs?
The longest worry is about the long term. If LLMs can find forty years of bugs that humans could not, how does the project catch up, and how does it keep innovating? Haas says he is not sure right now, only that he and many others are working hard on it. The post collected over 800 points and about 480 comments on Hacker News, which suggests the question applies to many code bases.
Robert Haas · Hacker News · news.ycombinator.com ↗From the field, part 1: it is repaying technical debt
Hacker News user BatteryMountain said that on their 1.5-million-line system they had found and fixed thousands of bugs, security holes and circular dependencies in the past year. Code quality and test coverage rose, and they set the compiler to treat warnings as errors. They called it impossible for human developers alone. Another commenter framed it as paying down technical debt, which beats shipping another major release with long-hidden bugs.
Hacker News user BatteryMountain and others · news.ycombinator.com ↗From the field, part 2: the haul was staggering
User tibbar wrote that AI-assisted bug hunting in Postgres over the summer between jobs turned up serialization anomalies, foreign-key integrity issues and planner correctness bugs, hundreds of candidates in all. They had to triage and reported only a dozen or two. Imagine, they wrote, the whole world doing this. Others, such as ltbarcly3, pointed out that big bugs also surfaced in late betas before AI and were wary of blaming AI alone.
Hacker News users tibbar and ltbarcly3 · news.ycombinator.com ↗For your own work: search got faster, verification did not
One commenter observed that AI is strong at read-only search tasks such as looking for bugs or vulnerabilities, and weaker at write tasks such as adding a feature, because search results are easy to verify and code changes are not. Haas's takeaway is that every PostgreSQL developer, and to some extent every software developer, must raise their game. Every feature written from now on will be scrutinized by AI, and problems that once escaped notice can be found within hours. He calls that both a challenge and an opportunity.
