Postgres 19 Is Late Because AI Outpaced Its Reviewers, and That Is Good Leadership
Postgres 19 is late because LLM assisted code review found a long tail of edge case bugs in old code, some with security implications. The release team chose to fix them and revert several late features rather than ship on schedule, putting reliability ahead of a longer feature list.
Postgres 19 Is Late Because AI Outpaced Its Reviewers, and That Is Good LeadershipAndrew Baker's Technology Blog Posts, 13/Nov/2026
https://andrewbaker.ninja/2026/11/13/postgres-19-is-late-because-ai-outpaced-its-reviewers-and-that-is-good-leadership/
If you read the headlines quickly, the story of PostgreSQL 19 sounds like a cautionary tale about artificial intelligence. One of the most respected open source projects on the planet missed its usual release window, pulled a handful of its most anticipated features, and its own developers pointed at large language models as the reason. On the surface that looks like proof that AI is slowing software down rather than speeding it up, and I suspect a lot of people outside engineering will read it exactly that way.
I read it very differently. What happened in the Postgres community this year is one of the clearest examples I have seen of a mature engineering culture doing the right thing under pressure. Machines started finding problems far faster than before, some in code that had been sitting there quietly for years and some in features that were still being prepared for this release. The people responsible for the release looked at that list, weighed what was genuinely risky, and decided that getting it right mattered more than shipping everything on time. That is not innovation slowing down. That is leadership.
Discovering more defects is not evidence that engineering quality has deteriorated. Very often it means your ability to detect defects has improved dramatically, and the real question is whether your organisation can absorb what it now sees.
1. What Actually Happened
For roughly a decade, a new major PostgreSQL version has landed somewhere between mid September and mid October. Version 19 broke that pattern. On October 10, Jonathan Katz of the release team told the hackers mailing list that general availability was moving to November 19, and the Release Candidate 1 announcement on October 15 confirmed the new date. A second release candidate shipped on November 12, deliberately released alongside the regular update for the older branches, because that update carried so many fixes that the team wanted them inside 19 before calling it final.
The delay arrived alongside something even more unusual than a slipped date. Robert Haas, one of the best known Postgres developers, noted that three major features were reverted between August 27 and September 15: UPDATE/DELETE FOR PORTION OF, SQL Property Graph Queries (SQL/PGQ), and ALTER TABLE MERGE/SPLIT PARTITION. Reverts that late in a beta cycle are rare, given that feature freeze happens in April. Peter Eisentraut, another long standing committer, put the broader count at roughly eight to ten significant features pulled from the release. The two numbers measure different things, with Haas naming the big late reverts in a specific window and Eisentraut describing the release as a whole, but the direction is the same either way.
The official Beta 4 announcement explained the reasoning in plain terms: the community believes very strongly that PostgreSQL has to be reliable, and it wants to keep the release schedule predictable. Faced with a choice between those two values and a longer feature list, the project chose reliability and predictability.
It is worth separating three things that the headlines tend to blur together, because the leadership lesson is stronger when they are kept apart. The first is AI assisted review discovering previously undetected defects in long established code. The second is AI assisted review finding problems in new features being prepared for version 19. The third is the decision to revert features and move the date, which was driven by a mix of defect remediation and human judgement about design. The stated reasons for the biggest reverts were mostly architectural: the SQL/PGQ revert commit cited multiple design issues that were too late to address in this release cycle, and MERGE/SPLIT PARTITION was pulled for similar design reasons. Online data checksums is the clearest case where LLM testing was directly involved, with the responsible committer opening a thread about trying to break the feature with LLMs before it was pulled. Snowflake’s engineers counted 53 individual reverts since beta began and said many of them came from in depth AI generated reviews, but nobody has published a per feature tally. So the honest summary is that AI did not personally cut these features; it raised the volume of findings and consumed the review capacity that would otherwise have gone into getting large new designs over the line.
2. The Numbers Behind the Delay
Haas did something I really appreciate, which is that he went to the commit history rather than relying on anecdote. Comparing the same post freeze window across two years, the number of commits landing on the stable branch being prepared for release rose from 724 in 2025 to 1,169 in 2026. Commits back patched to the previous stable branch rose from 248 to 433, an increase of more than 74 percent. These commits are not a count of unique bugs, since one fix can span several commits and some commits are housekeeping, but they are a reasonable proxy for remediation activity, and they were going into code that was already shipped or about to be.
{
"type": "bar",
"data": {
"labels": ["Branch being prepared for release", "Previous stable branch"],
"datasets": [
{
"label": "2025 cycle",
"data": [724, 248],
"backgroundColor": "#60a5fa",
"borderColor": "#1d4ed8",
"borderWidth": 1
},
{
"label": "2026 cycle",
"data": [1169, 433],
"backgroundColor": "#f59e0b",
"borderColor": "#b45309",
"borderWidth": 1
}
]
},
"options": {
"responsive": true,
"plugins": {
"title": {
"display": true,
"text": "Postgres stable branch commits in the post freeze window (Robert Haas)",
"color": "#9ca3af"
},
"legend": { "labels": { "color": "#9ca3af" } }
},
"scales": {
"x": { "ticks": { "color": "#9ca3af" }, "grid": { "color": "rgba(156,163,175,0.2)" } },
"y": { "beginAtZero": true, "ticks": { "color": "#9ca3af" }, "grid": { "color": "rgba(156,163,175,0.2)" } }
}
}
}The security side tells a similar story. One engineering analysis of the delay pointed out that PostgreSQL historically averaged a couple of CVEs per release, while the August 2026 update for version 18 alone fixed 28. The project’s own announcement for that August update lists 28 security fixes, and reporting from Magica tallied the security fixes in each of the 2026 update releases, and the trend line is hard to miss. I would treat these as reported counts rather than an official project statistic. They also do not tell us how many of those vulnerabilities were found by AI, since the project has not published a count of AI found bugs. What they do show is a sharp rise in security remediation work landing on the same small group of people, which is consistent with what the committers themselves are describing.
{
"type": "bar",
"data": {
"labels": ["February 2026", "May 2026", "August 2026"],
"datasets": [
{
"label": "Reported security fixes per update release",
"data": [5, 11, 28],
"backgroundColor": ["#60a5fa", "#a78bfa", "#f87171"],
"borderColor": ["#1d4ed8", "#6d28d9", "#b91c1c"],
"borderWidth": 1
}
]
},
"options": {
"responsive": true,
"plugins": {
"title": {
"display": true,
"text": "PostgreSQL security fixes in 2026 update releases (as reported)",
"color": "#9ca3af"
},
"legend": { "display": false }
},
"scales": {
"x": { "ticks": { "color": "#9ca3af" }, "grid": { "color": "rgba(156,163,175,0.2)" } },
"y": { "beginAtZero": true, "ticks": { "color": "#9ca3af" }, "grid": { "color": "rgba(156,163,175,0.2)" } }
}
}
}3. AI Was the Microscope, Not the Author
It is worth being precise here, because the lazy reading of this story gets the cause backwards. The problem was not that developers used AI to generate sloppy features which then had to be ripped out. Eisentraut explicitly rejects the idea that AI wrote the faulty code. What changed is that LLM assisted code review became good enough to surface long tails of edge case bugs that previously would only have shown up after a release, in production, in somebody else’s database. In his words, you end up staring at a list of like forty defect reports. He is also clear that this was not the only factor, pointing as well to architectural problems in some features and to review capacity that had been drained by the surge in security work.
Haas frames it in terms of the age of the codebase. The git history, converted from CVS, goes back more than 30 years, and the earliest code predates even that. Bugs have always been there. What is new is that they have become dramatically cheaper to find, while fixing them has not become cheaper by anything like the same amount. Fixes drafted by LLMs are not always correct and do not always meet the project’s standards, so a human still has to understand the problem, review the patch and commit it. That human step is where the release got stuck.
Some commentary has summed this up as AI finding old bugs in old code rather than new bugs in new code, but the evidence supports a broader statement. AI assisted review exposed defects in both established code and new features at a rate that overwhelmed the project’s existing verification capacity. The resulting delay reflects a higher quality bar, not a sudden collapse in engineering standards, and that distinction matters enormously for how we interpret it.
4. Development and Testing Are Antagonistic Muscles
I like to think about development and testing the way a physiotherapist thinks about the biceps and triceps. They pull in opposite directions, and that opposition is exactly what makes a joint strong and controllable. If one side becomes dramatically stronger than the other, you do not get a better arm; you get an injury.
For most of the history of software, the two muscles were roughly matched. Humans wrote code at human speed and humans found bugs at human speed, and release processes were tuned around that balance. What happened in Postgres this year is that one side of the pair, discovery, suddenly became enormously stronger, while the other side, the human capacity to triage, fix, review and commit, stayed exactly where it was. The joint did what joints do when they are out of balance, and the release slowed down to protect itself.
%%{init: {"theme": "base", "themeVariables": {"background": "transparent", "primaryColor": "#1e3a5f", "primaryTextColor": "#ffffff", "primaryBorderColor": "#93c5fd", "lineColor": "#f59e0b", "fontSize": "16px"}}}%%
flowchart LR
A["AI assisted review<br/>finds defects fast"] --> B["Queue of findings<br/>grows quickly"]
B --> C["Human triage<br/>real and how risky?"]
C -->|"Low risk"| L["Defer with<br/>tracking"]
C -->|"Unacceptable risk"| D["Human fix<br/>and review"]
D --> E["Commit and<br/>back patch"]
E --> F{"Release ready?"}
F -->|"No"| G["Cut scope<br/>revert features"]
G --> C
F -->|"Yes"| H["Ship"]
classDef fast fill:#7c2d12,stroke:#fdba74,color:#ffffff
classDef slow fill:#1e3a5f,stroke:#93c5fd,color:#ffffff
classDef decide fill:#14532d,stroke:#86efac,color:#ffffff
class A,B fast
class C,D,E,L slow
class F,G,H decideThe interesting thing about this picture is where the bottleneck sits. It is not in writing code and it is not in finding problems. It sits squarely in the middle, in the judgement work that only experienced engineers can do. Every organisation that points AI at a large legacy codebase is going to discover the same thing, and the ones that plan for it will look far better than the ones that are surprised by it.
5. Why Cutting Scope Is the Leadership Signal
Deciding to revert a feature is one of the hardest calls in software. Somebody has spent a year or more on it, users have read about it in the beta notes, and there is real pressure to ship it and patch it later. The SQL/PGQ decision is a good illustration. Tom Lane had warned beforehand that shipping it in version 19 risked post release bugs that could not be fixed until version 20, and the project listened.
%%{init: {"theme": "base", "themeVariables": {"background": "transparent", "primaryColor": "#1e3a5f", "primaryTextColor": "#ffffff", "primaryBorderColor": "#93c5fd", "lineColor": "#f59e0b", "fontSize": "16px"}}}%%
flowchart LR
A["April 8<br/>Feature freeze"] --> B["Aug 27 to Sep 15<br/>Three major reverts"]
B --> C["Sep 24<br/>Beta 4 confirms reverts"]
C --> D["Oct 10<br/>GA moved to Nov 19"]
D --> E["Oct 15<br/>Release Candidate 1"]
E --> F["Nov 12<br/>RC 2 released"]
F --> G["Nov 19<br/>GA planned"]
classDef step fill:#1e3a5f,stroke:#93c5fd,color:#ffffff
classDef cut fill:#7c2d12,stroke:#fdba74,color:#ffffff
class A,C,D,E,F,G step
class B cutWhat strikes me most is the proportion of the response. The project did not abandon its schedule entirely or declare a quality crisis; it moved the date by a few weeks and cut scope to protect the date it did set. Haas himself describes it as not a long delay, and one that comes from the project’s commitment to quality. That is exactly the posture I want from any team I lead. Mature engineering leadership is not about fixing every finding before release; that would simply swap one kind of paralysis for another. It is about distinguishing the genuinely unacceptable risks from the issues that can safely be deferred and tracked. When someone says “I found this thing, it has been there forever, it does not look right and it might be a security problem,” the correct response is to thank them, assess it properly, and if it lands on the wrong side of that line, make room to fix it rather than asking whether it can wait until after the launch.
Having spent most of my career in high frequency trading, building network stacks on FPGAs, I learned early that a bug in production is not an abstraction. It costs real money, immediately, and nobody cares how many features you shipped that quarter. That environment forces a culture where verification gates everything, and it is quietly satisfying to see an open source project arrive at the same instinct on its own.
6. Testing First Really Means Verification Capacity First
I want to be careful not to oversimplify my own argument. “Testing first, productivity second” is a useful slogan, but it makes the two sound like rivals competing for the same budget. I think the more accurate framing is that you can only be as productive as your ability to verify what you produce. Shipping features you cannot trust is not productivity; it is debt with a delayed invoice.
Haas is honest that the long term picture is less clear and in some ways more troubling than the short term one. The project now has to catch up on decades of latent bugs while also continuing to innovate, and he admits that he and others are working hard on the problem without being sure of the answer yet. That honesty is part of what makes this good leadership too. Choosing quality for one release is a decision; building the reviewer and fixer capacity so that the next release does not face the same squeeze is a strategy.
It is also fair to acknowledge the sceptics. Some of the community discussion questioned whether LLM assisted review is surfacing genuinely important bugs or simply generating a flood of noisy, hard to triage findings. Both can be true at once, and that is precisely why the human middle of the pipeline becomes so valuable. The cost of AI discovery is not the tokens; it is the expert time needed to separate the real issues from the noise.
That leads to what I think is the most important second order consequence. The next competitive advantage in software engineering will not come from the organisations that can generate the most code or discover the most bugs, because both of those are rapidly becoming cheap. It will come from the organisations that can verify, prioritise and safely remediate findings faster than their competitors.
7. What I Would Take Into a Bank
Banks run on large, old, critical codebases, which makes the Postgres experience a preview rather than a curiosity. The moment you point capable AI review at a core system, you should expect a wave of findings, some trivial and some genuinely serious, and you should plan for that wave before you switch the tooling on. That means agreeing a risk based triage policy up front, so that teams know which findings block a release and which are logged and scheduled, and budgeting senior engineering time for triage and fixes in advance, rather than discovering in the middle of a release that the people who could fix the problems are all committed to feature work.
It also means making scope cuts a normal and blame free part of how releases work. If the only acceptable outcome is “everything ships on the date,” people will hide findings or defer them, and the AI will simply be generating a list that nobody acts on. Fixed dates with flexible scope give teams permission to do what Postgres did.
Finally, I would change what gets celebrated. If the only engineering metric anyone talks about is features delivered, the latent defects retired from old code will always look like a cost centre. In a world where machines can find decades of hidden problems in an afternoon, retiring those problems is some of the most valuable work a team can do, and leadership needs to say that out loud.
8. The Takeaway
PostgreSQL 19 is a few weeks late and a little smaller than planned, and it will almost certainly be a better and safer release because of it. The headline says AI slowed Postgres down. The truth is that AI has changed the economics of finding defects, in old code and new, while engineering organisations have not yet adapted their capacity to resolve them, and the people in charge had the discipline to respond with judgement rather than paper over it. That gap between finding and fixing is a genuinely important leadership problem, and if agentic tooling forces more of our industry to confront it honestly, I will happily accept a few slipped dates in return.
References
Official PostgreSQL announcements
- PostgreSQL Global Development Group, PostgreSQL 19 RC 1 Released!
- PostgreSQL Global Development Group, November 12 update release and PostgreSQL 19 RC 2
First hand accounts from Postgres developers and contributors
- Robert Haas via Neon, Postgres 19 is late, and it’s AI’s fault
- Snowflake Engineering, What Is Happening with PostgreSQL 19?
- Command Prompt, Two features just left PostgreSQL 19
Analysis and reporting
- Braindetox, PostgreSQL 19 Beta Reverts: What Was Pulled and Why (compiles the stated reason for each revert from the Beta 4 announcement and mailing lists)
- Technology.org, PostgreSQL 19 Delayed After AI Review Finds Bugs
- FourWeekMBA, PostgreSQL 19 Slips to Nov. 19 as AI Code Review Finds Bugs
- daily.dev summary of The Register, Postgres 19 delayed after AI reviewers find more bugs than humans can fix
- Hardware Busters, PostgreSQL 19 Slips to November 19 as AI Found Bugs Swamp Its Human Reviewers
- Phoronix, PostgreSQL 19 Running Behind Schedule Due To AI/LLM Burden
- PBX Science, PostgreSQL 19 Delayed to November 19 as AI Found Bugs Overwhelm Developers
- Magica, PostgreSQL 19 delayed to November: AI assisted bug discovery
- DEV Community, Postgres 19 Proves It: AI Finds Bugs Faster Than We Fix Them
- Tech Insider, PostgreSQL 19 Delayed: AI Review Finds 40 Bugs