Postgres 19 is late because so many more bugs are being found now

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. It is absolutely amazing to see the gaps being filled, it would've been an impossible task for human devs and IDE's would've made it very uncomfortable. We've also ironed out all the bugs and failure modes in our infrastructure automation / monitoring. Our next project is to eliminate all 3rd party dependencies, and after that to rebuild our frontends completely using zero frameworks, not touching npm ever again after that.

So when I read this about postgres, I was very happy that they found and pursued this side quest. They can make the codebase bullet proof.

> 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 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 some time.

I did a little AI-assisted bug-hunting in Postgres this summer in between jobs, and the haul was staggering. Multiple serialization anomalies (eg [0] [1] [2]), foreign key integrity issues ([3] [4]), planner correctness bugs such as [5]. Various CVE-worthy vulnerabilities. An unfixable timezone bug [6]. The list got so long that I had to triage what I even had time to report, and settled for a dozen or two out of hundreds of candidates. Now imagine the entire world doing this.

[0] Write skew observed under serializable isolation: https://www.postgresql.org/message-id/flat/CA+COZaBo+ZpKgMvx...

[1] Serializable anomaly: duplicate primary keys: https://www.postgresql.org/message-id/flat/CA+COZaBOiiRPmEfX...

[2] SERIALIZABLE can commit write skew after SSI summarization: https://www.postgresql.org/message-id/flat/CA+COZaCtK=UQbeQw...

[3] Fix temporal foreign key validation of pre-existing rows https://www.postgresql.org/message-id/flat/CA+COZaChq_ukm2o7...

[4] Lost lock during toasting allows FK violation https://www.postgresql.org/message-id/flat/CA+COZaC-2-GQabq+...

[5] Partition pruning can incorrectly exclude a RANGE default partition https://www.postgresql.org/message-id/flat/CA+COZaDXrfTaBjLE...

[6] timestamp vs. timestamptz comparisons inconsistently ordered under DST : https://www.postgresql.org/message-id/flat/c22286ad6268347c6...

They can always do what the average commercial product company would do: Triage bugs for priority and make a cut-off. Effectively this leads to eternally-ignored niche feature bugs that causes frustration for the (few) people suffering from these bugs. But then again, if an LLM found a bug but no human ever, no one might actually care that much.

I feel like AI is amazing for read only “search” tasks (query this, look for bugs, find vulnerabilities) but it’s not quite as good for “write” tasks like “add this feature”. Search tasks are easily verified, code changes are much harder to verify

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.

Not specific re Postgres, just a general observation:

A pattern I'm seeing w/ companies and projects not used to continuous delivery (or at least shorter release cycles) is that they are slipping in schedules more now.

I think in the current environment it makes a lot of sense to re-think how often releases get cut and how to handle security related updates.

When you do only one or a few releases per year everything is 'higher' stakes and more bureaucratic.

I think it's a bit more nuanced than that https://vondra.me/posts/are-we-reverting-patches-because-of-...

The Joel Test: 12 Steps to Better Code: https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...

Step 5: Do you fix bugs before writing new code?

(now i feel old)

Makes sense. Code base is over 30 years old. Lot's of hands went into shaping it. There will be bugs as not one contributor as the entire codebase in their head. The testing is where bugs should be caught. Not by ones knowledge. I actually think there will be more bugs that come out of nowhere either found by humans or automation.

Seeing AI agents are founding and fixing bugs, I wonder about the future of "open source"

The process should now be: write your specs in lean, LLMs fill the gaps, then you translate the proof into your end product software. Otherwise LLMs will simply keep finding bugs, both in old and new code.

AI struggling a bit with legacy databases in a way that you need more iterations to really find all the bugs, otherwise it turns into "find bugs -> fix bugs -> find more bugs which were not found on step 1 -> fix regressions" and that repeats again and again :/ But I'm sure that Postgres team will handle that eventually and we'll get a better product in the end

There are always bugs in the code - AI is just a little more powerful tool to detect them. For me, the main outcome of a bug is whether it is a security breach or it exposes the need to change the whole architecture. In current Postgres, AI hasn't found such significant bugs yet.

So we have a new term: VDoS Deny a patch/version by burring the publisher with CVEs

If software as mature and widely-used as Postgres has this level of hidden bugs, what about the average software product?

Most of the parent comments in this thread did not seem to understand the article. So here’s the tl;dr

Postgres release is delayed due to the quality bar getting raised. New features are getting more eyeballs, and therefore leading to more rollbacks. Pre-existing releases are getting bug reports and backported fixes at much higher rate. Bug fixing might be taking away time from feature development, but does harden the codebase. LLM usage seems to have been a net positive.

Both OpenAI and Anyhropic use PostgreSQL. They could spare some processing capability to run the codebase through their most advanced models and output a cleaned up version with all the legacy cruft removed. It would give Postgres a major boost in reducing the codebase and the number of bugs present.

I hope the maintainers can make this release, and then just skip the next one to focus on bugfixing and the probable refactoring needed for some of the bugs.

“A wizard is never late, nor is he early; he arrives precisely when he means to” -- Gandalf

Given that the core feature of Postgres is rock-hard reliability, this is great news.

I wonder if the same is happening with mySQL? And if any of these would means OrioleDB takes a lot longer to be integrated?

I absolutely think that this is fantastic. LLMs are widely and so, everyone and their grandma has the capability to compromise on any system. We need to be more proactive on fixing bugs.

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 conservative in 2026 as they were in preceding years, but a lot more of the mistakes they made were quickly found by LLMs."

and

"And I think that’s also why we had so many late reverts, and why the release itself is delayed. Two factors are at play here."

so?

"it's AI's fault"

I missed when AI became accountable for Postgres releases, when did that happen?

bug resolution is more important it may be affect delivery date

Much need for Security

> 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, and how will PostgreSQL continue to innovate?

I mean, maybe just innovate less? "Innovation" is one of those words that makes me queasy nowadays. It's been true for decades that a good deal of what's touted as "innovation" is just stuff that is not actually as important as fixing what's already there. Most software releases new versions far too often for far too little reason. So overall it's good to see Postgres slowing down rather than just barreling ahead with a new release.

AI is great for one-shotting impressive demos and fixing well-defined things; it's not even close when it comes to very long context and really complex tasks. If you haven't created a harness around your complex application, the use of AI will hinder rather than help your project.

Is no one entertaining the possibility that some contributions were lower quality due to AI? I'm surprised to have only seen arguments that it's review.

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 unable to find but LLMs are quite capable of discovering, how are we ever going to catch up, and how will PostgreSQL continue to innovate? Right now, I’m not sure. What I do know is that I, and many others, are working really hard to figure it out.

Two thoughts:

1. If the signal quality is high--the bug reports are generally valid, the submitted fixes are generally viable (if needing some attention)--then this all seems great. Pause innovation for a while, you can afford it. Focus on burning down the bug count, and resume feature development when things are more stable.

2. If the signal quality isn't good, or is sufficiently mixed that a lot of time is being wasted on low quality contributions... that's more complex. I don't know what to do about that. Maybe stop accepting contributions from unknown contributors? No idea.

From the post I'm not sure whether they're experiencing a (1) or a (2). If it's a (1) that's really interesting, and gives me some glimmer of hope for the future.

[edit] this piece of shit website won't let me reply "you're posting too fast.." so I'll respond to the two replies here (gondalez and sverhagen had basically the same point):

Yes that's a very good point. Not every valid bugfix is equivalently urgent. That's another critical dimension of quality--not burdening maintainers with pedantic bugs. This kind of contextual nuance is, coincidentally, something AI is absolutely awful at.

Now, riddle me this. Does this mean productivity is up or down for the Postgres team?

So it seems there as a certain level of safety in obscurity that was acceptable / fine which has been lost and therefore the focus is shifting towards churning through the slop.

[flagged]

[flagged]

[dead]

[flagged]

> The short answer is that LLMs happened. All software contains bugs, and PostgreSQL’s code base is large, complex, and old. Our git history – converted from CVS – now reaches back more than 30 years, and the first code was written a decade before that. There’s a huge amount of code, and that code contains a huge number of bugs. That’s always been true, and it hasn’t stopped PostgreSQL from being popular or successful. What’s different now is that it’s become vastly easier to find those bugs. Fixing them has also gotten easier, but not to the same degree.

LLMs are a gimmick, btw. This is an Anthropic marketing stunt, how much did they pay you? /s

[flagged]

[dead]

TLDR After decades of being increasingly whittled down and optimized, an absoltuely fundamental piece of computing is now predomaitnely fixing bugs rather than adding new features.

[dead]

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 out.

https://www.postgresql.org/message-id/20140818195634.2543.56...

It seems quite possible that someone wants to make it seem like LLMs are causing problems by over-reacting to things that could just be fixed, or delay the release slightly (or maybe waiting until late before a release to kill features they don't like?) Whatever it is, this seems like a dysfunctional process.

I’m still amazed that with all the vibe coding, no one has created a Postgres alternative

postgres is mature database used the world over allegedly about to be on major version 19. how has the time not been spent already to get rid of the bugs?

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" is not there.

Anecdote, I did a travel across USA and when I was looking for a hotel, if you go from apple maps, to website, to try to book, the "load browser" in the maps... could end in states where you could not go back because back is get out of where you are and go back to the start of the map... and was a terrible experience... then you turbo charge it with "implement game changer UI improvements for the new bar on UI design" goal of some guy with enough power to make damage... and you end with softslop (or is it sloprosoft?)