Postgres almost never ships late. For about ten years now you could set your calendar by it: a major release lands somewhere between mid-September and mid-October, every single year. Version 19 broke that streak. It’s slipping into November, and the project isn’t ruling out pushing it further.
Robert Haas, one of the longtime committers, wrote up why, and his explanation is the most interesting thing I’ve read about AI and software all month. The short version is that large language models are now so good at finding bugs in Postgres that the humans can’t keep up with the fixes. That’s it. That’s the delay.
I’ve been chewing on this for a couple of days because I think it’s a preview of something bigger, and most of the AI-and-coding conversation is pointed in completely the wrong direction.
What the numbers actually show
Haas pulled the commit data, and it’s worth sitting with. Between feature freeze in April and late September, the number of commits going into the Postgres master branch barely changed year over year. If anything it dipped slightly. So the committers weren’t suddenly writing more or being sloppier.
The back-patches are where it gets wild. Commits back-patched to the in-progress release jumped more than 60% in a single year. Fixes back-patched to an already shipped prior release went up more than 74%. These are bugs in code that’s been sitting in production for years, sometimes decades, and all of a sudden they’re getting found and fixed at a pace nobody’s seen before.
The cause isn’t the committers. It’s everyone on the outside. People all over the internet are pointing LLMs at the Postgres source, the models are surfacing real defects, and those reports are landing in the maintainers’ laps faster than they can process them.
So Postgres 19 is late not because the code got worse. It’s late because the code is being examined more thoroughly than it ever has been in forty years, and the review bandwidth to deal with all of it simply doesn’t exist.
The part that doesn’t get talked about
Here’s what I keep coming back to. Every story about AI and code is about generation. Copilot writes your function, Claude builds your feature, some agent opens a PR while you sleep. The whole pitch is “the machine writes it for you.”
Nobody’s really talking about the other side, which is that the machine is now reading everything too. And reading, in this case, means finding every mistake you’ve ever made and quite a few that your predecessors made before you were born.
That’s a fundamentally different kind of pressure. Writing code faster is a productivity story. Having all your code continuously audited by tireless software that never gets bored is a quality-assurance story, and it’s being forced on open-source projects whether they asked for it or not.
The asymmetry Haas points out is the real problem. LLMs can draft fixes, sure, but a drafted fix isn’t a merged fix. Somebody still has to understand the bug, verify the patch is correct, check it doesn’t break something else, confirm it meets the project’s standards, and then actually commit it. The finding got cheap. The reviewing stayed expensive. And the reviewers didn’t multiply.
I’ve watched this dynamic before, smaller
Back in my AEM and enterprise days, the thing that killed teams was never the bug count. It was the triage. You could have a static analysis tool spit out four hundred findings on a legacy codebase and it was almost useless, because a human still had to sort the real issues from the noise, figure out which ones mattered, and decide what to fix before the next release. The tool created work. It didn’t finish it.
LLM bug reports are that same shape, except the findings are often real instead of lint noise, which makes them harder to ignore and more expensive to dismiss. You can’t just wave off a report that comes with a reproduction case and a plausible fix attached. You have to engage with it. Multiply that by “a huge number of people on the internet” and you’ve turned a stable release process into a firehose.
The Postgres folks are handling it about as well as anyone could. Haas is pretty clear that he’s not panicking, and a one-month slip on a project this careful is nothing. They reverted a few big features late, including some partition and graph-query work, partly because the review time that would normally go toward vetting new features got pulled into fixing the flood of back-branch bugs. That’s a reasonable trade. Quality over the calendar.
The uncomfortable long-term question
The honest bit of Haas’s post is the ending, where he basically says he doesn’t know how this plays out. Forty years of bugs that humans couldn’t find are now findable in an afternoon. If the discovery rate keeps climbing and the review capacity stays flat, how does a volunteer-heavy project ever catch up? And while it’s drowning in old bugs, how does it find the time to build anything new?
I don’t have a clean answer either. A few things seem likely though.
- Projects are going to need AI on the defending side too, not just the attacking side. If LLMs are generating the reports, LLMs are going to have to help triage, dedupe, and pre-validate them before a human ever looks. Otherwise the asymmetry just gets worse.
- “Found a bug” is going to stop being enough. The valuable contribution becomes a confirmed, reproduced, standards-compliant, reviewed fix. The bar for a useful report goes up, not down.
- Maintainer time becomes the scarcest resource in open source, more than it already is. Anything that burns it carelessly, including low-effort AI-generated reports, is going to get a frostier reception.
There’s a version of this that’s genuinely good. Postgres is getting more robust because of it. Decades-old latent defects are getting cleaned out. The code everybody depends on is quietly becoming more correct. I don’t want to lose sight of that.
But I also think Haas is right that every developer is about to feel this. Not just the Postgres committers. Every feature any of us writes from here on gets examined by software that doesn’t sleep, doesn’t skim, and will happily point out the edge case you convinced yourself nobody would ever hit. The stuff that used to slip through and sit unnoticed for years has a much shorter shelf life now.
So what do I take from this
Mostly that the interesting frontier in AI-and-code isn’t “it writes my boilerplate.” That part’s real and fine and already priced in. The frontier is what happens to software quality and maintainer sanity when discovery becomes nearly free while judgment stays expensive and human.
Postgres 19 being a few weeks late is a small, almost funny symptom of a shift that’s going to reshape how open source operates. If your project depends on volunteer reviewers and you haven’t thought about what a flood of credible AI bug reports does to them, now’s a decent time to start. The reports are coming. They might already be in your inbox.