PostgreSQL 19 delayed to November as LLM-found bugs overwhelm committers
A surge in AI-discovered bugs has forced major feature reverts and pushed the release beyond its traditional October window.
What to know
- PostgreSQL 19 is delayed beyond its traditional October release window to November because LLM-assisted bug discovery has overwhelmed the project's commit and review capacity.
- Back-patched bug fixes to stable branches jumped 60–74% year-over-year, and three major features were reverted late in beta due to quality issues.
- The bottleneck is not finding bugs—LLMs excel at that—but reviewing, validating, and implementing fixes with a fixed number of human committers.
- The PostgreSQL community is divided on whether this represents a net gain (higher quality baseline despite slower feature delivery) or a sign that quality assurance cannot scale.
The dispute Whether the delay reflects a temporary correction phase (discovering and fixing decades of accumulated bugs) that will eventually stabilize, or a permanent new reality where LLM-generated reports will outpace human review indefinitely. · positions read across 84 posts and comments
LLM-driven discovery is a net win; higher quality justifies delayed releases.
-
“This seems…good? That it might disrupt the project's "traditional" release cadence a bit doesn't seem terribly bad in light of the alternative, which is shipping another major update with bugs which have apparently haunted the codebase for…”
CharlesW · Hacker News ↗
Review and validation, not discovery, is now the bottleneck; unclear if reports are high or low quality.
-
“I guess the real challenge is figuring out how to scale verification, cause discovery isn't the bottleneck anymore.”
droppedasbaby · Hacker News ↗
LLM is genuinely surfacing critical security-class bugs that were invisible before.
-
“I did a little AI-assisted bug-hunting in Postgres this summer… Multiple serialization anomalies, foreign key integrity issues, planner correctness bugs. Various CVE-worthy vulnerabilities.”
tibbar · Hacker News ↗
Robert Haas PostgreSQL major contributor, Databricks Sr. Staff Engineer
How it unfolded 4 developments, newest first · click a bar or a number to jump postscomments
-
4
Commenter frames delay as quality bar rising, not catastrophe
A Hacker News user summarized the article for readers, framing the delay as a positive outcome: the project's quality bar has risen due to more scrutiny, features are getting safer, and the codebase is hardening despite temporary disruption to release cadence.
“Postgres release is delayed due to the quality bar getting raised. New features are getting more eyeballs, and therefore leading to more rollbacks.”
— flakes -
So I read this title and thought "ah great, yet another article complaining about vibecoded features and their slop". But then I remembered reading some other article about PostgreSQL 19 in the last few weeks and how it claimed that none of its features had been written with the help of LLMs. Which made me curious to read it. The premise of the…
2 more of the top 3 · 71 posts in this stretch
-
I know that it's a good thing in almost every way that these bugs are being found which used to be left undiscovered, especially security bugs, knowing that state actors probably have a significant stash of them documented and ready to use when needed.But.Something's lost in this need for perfection, knowing that every bug will be found quickly…
-
H
Postgres 19 is late because so many more bugs are being found now Link: http:// rhaas.blogspot.com/2026/10/pos tgres-19-is-late-and-its-ais-fault.html Discussion: https:// news.ycombinator.com/item?id=5 0312408
-
-
3
Commenter reports AI-assisted discovery of critical vulnerabilities, predates article
A Hacker News commenter disclosed finding dozens of security-class bugs in PostgreSQL using LLMs over the summer—serialization anomalies, foreign key integrity issues, CVE-worthy vulnerabilities—and noted the discovery rate was so high they had to triage reports rather than submit them all.
“I did a little AI-assisted bug-hunting in Postgres this summer… Multiple serialization anomalies, foreign key integrity issues, planner correctness bugs. Various CVE-worthy vulnerabilities.”
— tibbar -
I'm not very positive on the social, technical, or intellectual impact of AI on software development. Actually, that's understating it. I think AI is basically cancer for the mind. That said, this framing gave me pause:> The long-term picture is less clear and in some ways more troubling: given that we have forty years of bugs that humans were…
2 more of the top 3 · 12 posts in this stretch
-
I have found major bugs in late beta's of postgres long before AI came along. I found a bug where malformed json would segfault the entire server (a segfault in a server process forces the entire cluster to shut down by design) when using jsonb in a release candidate once. They fixed it rather than ripping the entire feature…
-
> This year is going to be different. PostgreSQL 19 most likely won’t be released until November… […] So, what happened? The short answer is that LLMs happened. […] There’s a huge amount of code, and that code contains a huge number of bugs. […] What’s different now is that it’s become vastly easier to find those bugs.This seems…good?That it might…
-
- 1 day quiet
-
2
Hacker News users debate whether bug discovery or review bottleneck is the real problem
Commenters questioned whether the delay stems from a flood of legitimate, high-quality bug reports or low-quality ones that maintainers must triage. Some praised LLM-assisted testing as a net positive; others noted that discovery speed does not automatically translate to faster fixes when the same small group of maintainers must validate and review each report.
“I guess the real challenge is figuring out how to scale verification, cause discovery isn't the bottleneck anymore.”
— droppedasbaby -
I guess the real challenge is figuring out how to scale verification, cause discovery isn't the bottleneck anymore. Generating more bug reports doesn't necessarily translate into faster fixes if the same small group of maintainers still have to validate the reports, review fixes, etc.
-
-
1
Robert HaasLLM-driven bug discovery has delayed PostgreSQL 19
Haas, a PostgreSQL major contributor, published an analysis showing that language models have found so many bugs in PostgreSQL's codebase that the project cannot ship version 19 on its traditional October schedule. Between April and September 2026, back-patched commits to stable branches jumped 60–74% compared to 2025, and three major features were reverted late in beta due to quality concerns.
“The short answer is that LLMs happened. All software contains bugs… What's different now is that it's become vastly easier to find those bugs.”
— Robert Haas -
first by LWN, 12d ago
-
What people are saying 18 voices from 3 sites · best of 84 · verbatim
- How long will the surge in bug discovery persist before only a long tail of minor issues remains?
- Are the LLM-generated bug reports mostly high-quality, or is the team drowning in false positives?
- How will the PostgreSQL project scale validation and review to match the new discovery rate without burning out committers?
- Nov 2
-
> It’s possible that some of this jump is the result of committers making more mistakes this year than they did last year, but I don’t think anyone who works on the project really believes that’s the main cause. Rather, it seems likely that PostgreSQL committers were about as conservative in 2026 as they were in preceding years, but a lot more of…
-
As someone who has been loudly in favor of LLMs for quality over velocity, I've really been struggling with a lot of this. Look, a lot of the systems I help maintain are quite good, right? Not to toot my own horn too much but I've been repeatedly recognized for being able to write solid, high-quality systems. Well, I pointed LLMs at some of those…
-
I have mixed feelings about this post and the reactions to it. Over the years I have evolved from "oo, shiney Nosql, that looks new" to "just use Postgres, it's the standard and its solid". That postgres basically gobbles most new db paradigms, rendering all but the most niche-needy adopters with no choice but to stick with postgres, speaks of a…
-
I feel like this is _exactly_ they way it should be done.
-
Like the warnings as errors, and extensive test suites, there's also type safety that helps stir the LLM in the right direction.You can go with "eliminate all 3rd party dependencies [...] frontends completely using zero frameworks" and be stuck with JS. Or use a typed language (TS, ReasonML/ReScript or even Elm) and an API client generator…
-
Nobody having reported a bug doesn't mean nobody is impacted. DB bugs are hard to reproduce because they're often non-deterministic, and only occur in rare conditions.
-
It is; certainly if it produces observable behaviour that was unintended but people now rely on (Hyrum’s law), and is now blocking features or performance patches, for example.
-
AI makes it possible to fix bugs and solves issue one wouldn't do before. But just because it's easier now doesn't mean it's automatically worth it. There are tradeoffs (like code complexity or breaking stuff), or it really just wasn't that important to fix if it was in the backlog forever. I've seen devs go down this rabbit hole, and perhaps…
-
I think in the author's eyes that more bugs were found is also a good thing: > In the end, I don’t think that the delay in shipping PostgreSQL 19 is particularly concerning. It is not a long delay in the grand scheme of things, and it emerges directly from the project’s concern for quality. Nonetheless, I think he might also be concerned about the…
-
I am wondering: if we leave security bugs out of the picture, is a bug really a bug if no-one was impacted by it over a long enough time and a wide enough install base?
-
As much as I dislike LLMs, this seems… fine? We’re living in the age of slop where velocity is prioritized over quality. Going the other direction is good.
-
Indeed. I would also prefer more bugfixes in pgsql 19 than new features. IMO this is a golden oppurtunity to postpone new features to version 20.
-
Exactly. It means that this iteration of Postgres was forcefully pushed into the “stabilisation” phase, which overall may be a good result for everyone, as a robust base is a better starting point for the new features. But it obviously frustrates some developers who can not push new stuff as fast as they wanted.
-
This is a good thing. Repaying technical debt is always a great thing.On our own 1.5M loc system, we've found and fixed thousands of bugs, security holes and circular dependencies in the last year. Code quality has increased, test coverage increased. We've also recently set our compiler to treat warnings as errors, and to be as strict as possible…
-
Ok, but does (s)he know? It's just guessing, so unfounded non-news?"It’s possible that some of this jump is the result of committers making more mistakes this year than they did last year, but I don’t think anyone who works on the project really believes that’s the main cause. Rather, it seems likely that PostgreSQL committers were about as…
-
> This seems…good?You would think so but medicine has faced this paradox since the development of modern testing technology.You would naively think more testing is always better. More sophisticated practitioners then talk about Type I vs Type II errors and the problem of false positives.But even if you were able to come up with tests that had 100%…
-
N
Postgres 19 is late because so many more bugs are being found now: http:// rhaas.blogspot.com/2026/10/pos tgres-19-is-late-and-its-ais-fault.html Discussion: http:// news.ycombinator.com/item?id=5 0312408
- Nov 1
-
I sometimes think that the world would need to do a "snow leopard" release of everything... to unit test, to fix... and then we will be able to move forward... but AiMaxSlopIt will result in those situations where you have to rollback or redo from scratch parts... because it's unmantainable because it's bad... it's spread everywhere and "the map"…