If there’s one open source project you can rely on for planning, it’s PostgreSQL. For a decade now, every major version has shipped between mid-September and mid-October, with a regularity many commercial products would envy. This year will be different: Robert Haas, a long-time PostgreSQL committer, explains in Postgres 19 is late, and it’s AI’s fault that version 19 won’t ship until November at the earliest, and that a further delay isn’t ruled out.
The headline sounds like a provocation, but the argument isn’t that AI writes bad code. It’s the opposite: AI finds bugs much faster than humans can fix them.
Three features pulled at the last minute
The first thing that stands out is what was left out. Between August 27 and September 15, three large features that were already in the beta were reverted:
UPDATE/DELETE FOR PORTION OF, to modify only a time slice of a row in tables with periods.- SQL/PGQ (SQL Property Graph Queries), the graph queries from the SQL standard.
ALTER TABLE ... MERGE PARTITION / SPLIT PARTITION, to merge and split partitions.
Reverting a feature right after feature freeze (which falls on April 8 every year) is normal. Reverting three features of this size in the middle of the beta, almost in September, is not. I was looking forward to SQL/PGQ in Postgres, so it’ll have to wait for 20.
The numbers
Haas compares the same period, April 8 to September 25, in 2025 and 2026:
| Branch | 2025 | 2026 | Change |
|---|---|---|---|
master | 1,037 | 1,443 | +39% |
Stable branch of the upcoming release (REL_18_STABLE / REL_19_STABLE) | 724 | 1,169 | +61% |
Previous stable branch (REL_17_STABLE / REL_18_STABLE) | 248 | 433 | +74% |
The interesting part is what’s growing. Commits that go only to master (the totals minus those also applied to the stable branch) actually dropped a little, from about 313 to about 274. What has shot up are backports, fixes applied to the release about to ship and to earlier ones as well. And 74% more commits on the previous release’s branch means they’re not just fixing freshly introduced mistakes, but bugs that have been there for years.
Haas is blunt about it: nobody on the project believes committers got sloppier from one year to the next. What changed is that a huge number of people are reporting bugs they found with LLMs.
Finding is easy, fixing not so much
The explanation for the delay has two parts.
The first is pure capacity. An LLM can find a bug in minutes and even propose a patch, but those patches aren’t always correct or compliant with the project’s standards. Someone has to review and commit them, and in Haas’s words, those humans haven’t gotten any smarter between 2025 and 2026.
The second is about priorities. Time that in other years went into reviewing what was going into the new release was diverted into fixing security issues and other bugs in the older branches. That’s why it took longer to decide what had to be reverted, and why the reverts came so late.
It’s exactly what I wrote about a few weeks ago in AI agents write more code, but companies don’t ship more software: the bottleneck isn’t producing, it’s reviewing. Here we see it from the other side. It’s not more new code that’s overwhelming reviewers, but more bug reports, and the effect is the same.
Forty years of bugs
Haas doesn’t find the delay itself worrying. A few weeks is nothing, and the delay comes from the project taking quality seriously. What does concern him is the long-term picture. PostgreSQL’s code started being written some forty years ago, and the git history, converted from CVS, goes back more than thirty. If there are forty years of bugs that humans couldn’t find and LLMs can, how do you ever catch up? And how does the project keep innovating in the meantime? He admits he doesn’t know yet.
What I find interesting is that he doesn’t frame it as a criticism of the code. Quite the opposite: he says PostgreSQL’s is one of the cleanest, highest-quality code bases he has ever worked on, and that if it had more defects visible to the naked eye, LLMs would find even more. It’s not that Postgres is badly built. It’s that all software has bugs, and now there’s a tool that surfaces them at a pace that didn’t exist before.
My takeaway
We’ve been seeing the same story from different angles for months: AI helping to formally verify entire libraries, finding vulnerabilities, swamping maintainers with reports. The Postgres case strikes me as particularly clear because it comes with data, it comes from inside the project, and it’s about one of the most careful open source projects out there.
One comment on the post sums it up well: attackers have LLMs too. If a bug can be found in hours with an AI, it’s not enough that nobody happened to find it before. The bar has been raised for everyone, and Haas ends on exactly that note: everything we write from now on will be scrutinized by AI, and things that would have gone unnoticed forever will be found, perhaps in a matter of hours. It’s a challenge, but also an opportunity: Postgres 19 arrives later and with fewer new features, and it will probably be one of the most solid releases the project has ever shipped.
Source: Postgres 19 is late, and it’s AI’s fault, Robert Haas (originally published on the Neon blog).
