Postgres 19 Is Late Because LLMs Found Forty Years of Bugs

Postgres ships in September or October. It has done, reliably, for years. You could set a calendar by it, and I more or less have.

Version 19 is now expected around November 19. Three significant features got pulled out of it late in beta — the kind of late where pulling a feature is itself the news.

Robert Haas has been committing to Postgres for the better part of two decades. He wrote up why, and his explanation runs four words:

The short answer is that LLMs happened.

I've read a lot of takes this year about what AI is doing to software. Most of them are somebody's product pitch wearing a blog post as a costume. This one isn't. It's a maintainer with commit data, explaining something that actually happened to a database you've probably got in production right now.

And the conclusion he lands on isn't the one either camp wants.

What got pulled

Three major features, out between August 27 and September 15:

• UPDATE/DELETE FOR PORTION OF
• SQL/PGQ — SQL Property Graph Queries
• ALTER TABLE MERGE/SPLIT PARTITION

All three now aimed at Postgres 20.

SQL/PGQ is the one that stings. It's been in the SQL standard since 2023. It's the feature that'd let you run graph queries against relational tables without bolting a separate graph database onto your stack, which is a thing a lot of people have wanted for a long time.

Tom Lane's assessment, quoted by The Register, is the kind of thing you only say when you've watched this movie before:

At this point I'd be willing to bet dinner that if we ship it in v19 there will be post-release bug discoveries that are unfixable until v20.

That's a specific fear and it's worth unpacking. Once a feature ships in a Postgres release, its on-disk format and its user-visible behaviour are close to frozen. Fixing a design mistake can mean breaking compatibility, and you can't do that in a minor release.

So shipping a feature you're unsure about doesn't defer the problem a few months. It defers it a year and makes it worse.

One note on counting, because the coverage differs and you'll see both numbers. Haas names three features pulled late in beta. The Register reports "between eight and 10 significant features" dropped from 19 overall. Not contradictory — different windows, different bars for "significant" — but that's why.

The commit data is the actual story

Here's where it stops being anecdote, and where it points somewhere I didn't expect.

Between feature freeze and September 25, master-branch commits went slightly down year over year. Meanwhile:

Read that properly, because it kills the explanation everyone reaches for first.

If committers had got sloppy — if people were vibe-coding features into the database — you'd expect new-feature work up and quality down. That is not what happened. New work went down. What exploded was fixing old code, on stable branches, in releases that already shipped years ago.

Haas's read: nobody got careless. The bugs were already in there. What changed is that finding them got easy.

it's become vastly easier to find those bugs

And a lot of the reports are coming from outside the project — people pointing LLMs at the Postgres source and filing whatever falls out.

Peter Eisentraut, a committer and VP at EDB, makes the same point from another angle, and I think his phrasing is the sharpest thing anybody said about this:

The effective quality bar has been raised after the time the feature was written and committed.

Nobody moved the goalposts on purpose. The goalposts moved because the measuring instrument got better. Code that was acceptable in 2019 — not because anyone was lazy, but because the review tools available couldn't see that deep — is now visibly not acceptable. Same code. Different world.

Eisentraut is explicit that this was not a vibe-coding problem, and I want to repeat that because it's the thing people will assume. The technique didn't exist when most of these features were written. Some of the reverted ones had "significant architectural defects" that just couldn't be fixed quickly during beta.

Why finding bugs faster made everything slower

This is the counterintuitive bit, and it's the part worth carrying into your own work.

The issues LLM review surfaced were mostly, in the project's own words, a long tail of relatively harmless edge cases. Things that would likely have shown up years later, if ever. Each individual fix is small.

But every report carries fixed overhead. Somebody reads it. Decides if it's real. Works out whether it's reachable. Checks whether the proposed fix is correct. Reviews it. Commits it.

That overhead doesn't shrink because the bug is minor. And it gets paid in the one thing a volunteer-heavy project can't buy more of: committer attention.

Haas is direct that AI-drafted fixes don't remove the cost either. They "aren't always correct or compliant with PostgreSQL standards," so a human reviews and commits every single one.

Then the knock-on. Review time that should have gone into deciding what ships in 19 got pulled into security issues and back-branch bugs instead. So the project hit the end of beta with less clarity than usual about what was safe to ship.

Which is exactly how you end up pulling three features in three weeks.

This clarified something I'd been chewing on from somewhere else entirely. Ruby Central ran AI models over 317 heavily-downloaded gems, and their human reviewers rejected 120 of 134 findings — ninety percent — because they weren't reachable by an attacker. Six real advisories came out of it, including an authentication bypass in a gem with 94 million downloads.

Both things true at once. Two unrelated projects. Same shape.

The scan is cheap. The triage is the entire cost. And nobody's pricing that in when they pitch you AI code review.

The question nobody has an answer to

Haas isn't especially bothered about the delay itself. He frames it as the project's quality focus working as intended, which it is. What worries him is longer-term, and he says it plainly:

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

Sit with that, because it generalises to every mature codebase on earth.

Postgres is forty years old. By any reasonable measure it's one of the best-maintained pieces of software in existence — I'd trust it over most things I've run, and I've run a lot of things I didn't trust. And it is now carrying a backlog of discoverable defects nobody can size, because until this year the tool that could find them didn't exist.

Your codebase is in the same position. So is mine. The difference is Postgres has committers who'll work through it, and a release process that'll slip to accommodate it.

The uncomfortable follow-on: the bug-finding capability scales and the bug-fixing capability doesn't. Anybody can point a model at a repository. The number of people qualified to review a Postgres storage-layer patch is not a number that goes up because inference got cheaper.

Haas calls it "a challenge and an opportunity," which is the diplomatic version. The blunt version is that review capacity is now the bottleneck for open source — and it was already the bottleneck before anyone bolted a firehose to the front of it.

What this doesn't mean

It doesn't mean Postgres 19 is bad. Eisentraut expects it to be "a great release," and it still has REPACK CONCURRENTLY, which is a real quality-of-life win if you've ever had to reclaim table bloat on a live system at two in the morning.

It doesn't mean LLM code review is a bad idea. It found real architectural defects in features about to ship into a release with a five-year support window. Catching that in beta is the system working. Catching it in 19.3 would have been a great deal worse.

It doesn't mean AI wrote bad code into Postgres. Eisentraut addressed that head-on — most of these features predate the tooling. The code was already like that. We just couldn't see it.

And it doesn't mean your upgrade plan changes. Waiting on 19 for SQL/PGQ? You're waiting for 20. Otherwise November instead of October isn't worth re-planning around. If you're running something properly ancient, the database EOL migration guide is a better use of your attention than a four-week slip in a release you weren't deploying on day one anyway.

The thing I keep turning over

I've spent years being skeptical of tools that promise to find my bugs for me. Mostly because the ones I used generated more noise than signal, and I ended up ignoring them — which is the worst possible outcome. Then you've got a dashboard full of warnings nobody reads and a comfortable feeling that something is being checked.

This is different, and I'd rather say so than defend a position I've held for a decade.

The Postgres case isn't a vendor demo. It's a project with a forty-year reputation for carefulness, publicly slipping a release because the bug reports got too good. That's not noise. That's a measurable change in what's findable.

What hasn't changed is who pays. The scan got cheap. The person who reads 134 findings to get to the 14 that matter did not get cheap, doesn't scale, and in most open source projects is doing it on a Sunday afternoon for nothing.

Postgres can absorb that. It has the committers, it has the discipline, and it just proved it'll move a release date rather than ship something it isn't sure about. That's the system working. It cost them a month.

I'm a lot less sure about everybody else. Something similar's been happening in the kernel — I wrote about Torvalds and AI-assisted patches earlier. And the projects I'd actually worry about are the ones with one maintainer and a full inbox.

They're going to get the same firehose. They don't have a Robert Haas to absorb it.