Postgres 19 Is Late Because AI Finds Bugs Faster Than Humans Can Fix Them

PostgreSQL has shipped a major version between the middle of September and the middle of October for about a decade. Version 19 will miss that window by roughly a month. On October 30, major contributor Robert Haas published a post with the title "Postgres 19 is late, and it's AI's fault", and the short answer inside it is one sentence: LLMs happened.

Nothing is on fire. The database did not break, nobody lost data, and the delay is small in the scale of a project with a thirty-year git history. What happened is more useful than an outage: finding bugs got dramatically cheaper, fixing them did not, and the gap was big enough to bend a release schedule that had been stable for years.

This is the first time we have seen that arithmetic measured on a codebase this large, and the numbers are worth reading closely, because the same shape is coming for anyone whose work is now judged by output a machine can produce faster than a person can check it.

The numbers, in the direction that matters

Haas compared commits in two matching windows, April 8 to September 25, in 2025 and in 2026. April 8 is feature freeze, so this covers the stretch where a release is supposed to be stabilizing.

• Master branch commits went from 1,037 to 1,443.
• Commits back-ported to the stable branch for the release in progress went from 724 (REL_18_STABLE) to 1,169 (REL_19_STABLE). That is up 61%.
• Commits back-ported at least one release further back went from 248 (REL_17_STABLE) to 433 (REL_18_STABLE). Up 74%.

The third line is the interesting one. Fixing the version you are about to ship is ordinary release work. Reopening the version you already shipped, and the one before that, is where the year went. He notes that master-only commits in the same window actually declined slightly, which rules out the easiest explanation, that committers suddenly made more mistakes. The work that grew is repair work.

He also names the features that were pulled late, between August 27 and September 15: UPDATE/DELETE FOR PORTION OF, SQL property graph queries, and ALTER TABLE MERGE/SPLIT PARTITION. Reverts right after a freeze are normal. Three substantial ones a month before release are not, and Peter Eisentraut's account from October 9 does not settle on a single cause for them. Security work consumed senior reviewers through the spring and summer, which cut into the extra review a beta period usually gets. LLM-assisted review raised the effective quality bar after those features had already been written. Some of the designs were also too complex to repair inside a beta at all.

Where the hours actually go

Peter Eisentraut, another member of the project's leadership, described the mechanism a few weeks earlier in a post he titled "The reverts will continue until morale improves". A list of around forty bug reports, each one maybe a three-line fix, and an irreducible cost per report: read it, reproduce it, decide whether it is real, shape the patch to project standards, commit it. Even if every item needs three lines of code, processing them takes time that cannot be compressed, and eventually the time is gone.

Haas adds the part most writing about AI-assisted development leaves out. LLMs can draft fixes, but "those fixes aren't always correct or compliant with PostgreSQL standards." They still need a human review and a human commit, and, in his words, "those humans have not gotten any smarter between 2025 and 2026."

So the model did not remove work from the system. It moved work from discovery to verification, and verification is the part with a fixed number of people in it. In his framing the project is sitting on forty years of bugs that human eyes could not find and that a language model can now surface in an afternoon.

This is not the AI slop problem

Most open source complaints this year were about noise. curl ended its bug bounty in January specifically to stop low-quality reports. Linus Torvalds called the duplicate storm around Linux "perfectly useless agitation", with many people finding the same issue with the same tools. On October 1, Google stopped accepting product vulnerability reports through its open source reward program, saying a significant rise in automated submissions was mostly invalid. Supply chain reports stayed open, and Google committed to an update in the first quarter of 2027.

Postgres is the other failure mode, and the harder one to design around. The reports were real. The people filing them were not being lazy. The volume simply exceeded the review capacity that existed, and unlike spam, you cannot filter it away without losing information you actually want.

That distinction decides your response. A noise problem is a triage problem: reject faster, close duplicates, cut the incentive. A real-volume problem is a capacity problem, and the honest options are to slow the feature work, grow the reviewer pool, or accept the slip. Postgres took the first and the third, which is why a release moved and the quality bar did not.

The same shape in creative work

Any pipeline that just got a fast producer now has a slow reviewer at the end of it. Image generation is the clearest case for us. A local model on a decent card returns a grid in under a minute, a hosted model returns four variations while you are still deciding what to type, and the number of frames you could look at has not changed at all.

Two hundred outputs and no selection process is not throughput. It is a backlog with pictures in it, and it fails in the same way Postgres failed: the expensive step is the judgment, not the production.

Three habits transfer directly from what happened here.

Generate at the rate you can review in the same sitting. If you cannot look at every frame before the next batch exists, you are not iterating, you are accumulating. Optimize the review, not the render.

Keep the making lane and the fixing lane separate. Haas's second finding is the one to copy: time that should have gone into shipping new work went into repairing old work, and the project responded by cutting scope deliberately instead of letting both lanes starve. In a creative pipeline that means a pass where you only compare and reject, with generating switched off, then a separate pass where you make.

Count the repair pile. Nobody in this story noticed the trend by feel. Someone compared two comparable windows of commits and the number was 61%. The equivalent for you is the count of near-final files waiting for a decision, which is invisible until you write it down.

There is also the less comfortable reading. If a model can find defects in anything, every asset you publish gets judged against a standard you did not have to meet a few years ago, and the problems that would have slipped past forever are now found in hours. Haas ends his post there: the work will be scrutinized, and everyone has to raise their game. We have seen versions of this in the queue that builds up behind agent-made work and in the gap between a preview and a published asset. This time it came with commit counts.

What we take from this

The release outcome is healthy. Postgres 19 is scheduled for November 19, with a final test build on November 12, and the project is late because it chose to fix what it found instead of shipping over it. A database with a thirty-year history behaving this way is reassuring.

The part to carry forward is the asymmetry. Discovery became parallel, cheap, and available to everyone at once. Verification stayed serial, human, and expensive, and no one got faster at it. Every field handing a high-throughput generator to people who still have to judge the output is about to run this experiment. Postgres ran it first, counted it, and published the numbers.