Postgres 19 is late: AI is finding too many bugs

Postgres 19 was supposed to ship in September, like almost every major release of the project. It still hasn't. The reason is curious. There's no shortage of code. There's a surplus of bugs. Robert Haas, one of the longest-standing PostgreSQL committers, wrote a post with a blunt title: Postgres 19 is late, and it's AI's fault. According to him, AI tools are finding problems at a pace the community has never seen, and that pushed the schedule back.

This news is worth a minute of your time. It says a lot about Postgres 19. But it says even more about how software will be built from now on.

Why is Postgres 19 late?

The Postgres cycle is very predictable. Feature freeze in April, betas mid-year, then a release candidate and the launch around September. Postgres 17 shipped in September 2024. Version 18 shipped in September 2025. You can plan upgrades around that.

In 2026 the machine got stuck in the stabilization phase. That's when people test what made it into the freeze and fix whatever turns up. The problem is that a lot more turns up now.

Researchers and contributors started pointing AI models at the Postgres source code. The models read the C, look for strange code paths, generate test cases and report back. Some of it is noise. But a meaningful share is real bugs: race conditions, edge-case errors in memory handling, wrong behavior in rare combinations of features.

And Postgres has a policy I really respect. A known bug in a new feature doesn't go into a release. If it can't be fixed safely, the feature gets pulled or the release waits.

The bottleneck isn't finding bugs, it's fixing them

This is the part I find most interesting. Finding bugs got cheap. Fixing them is still expensive.

For every report, someone has to:

• reproduce the problem
• figure out if it's a real bug or a false positive
• write the patch
• review the patch (in Postgres, that's serious business)
• make sure the fix doesn't break something else

None of these steps got ten times faster. Only the first one did. The result is a growing queue on the side of the people with commit access, and that's a small group of very experienced people.

Finding bugs became a commodity. Reviewing is still craftsmanship.

If you've ever maintained a popular repository, you know the feeling. You open GitHub in the morning and there are 40 new issues. Half are duplicates, maybe five are real and serious. Now picture that in a database that runs the finances of half the world, where a bad patch turns into data corruption in production.

Is this good or bad?

My strong opinion: it's good. Very good, actually.

Those bugs were already there. AI didn't create any of them. It just turned on the light in a room that was dark. The alternative was you finding the same bug at 3 a.m., with the database locked up and Slack on fire.

A delay of a few weeks, or a few months, on a database that will run on your server for five years is a small price. I'd take a late Postgres 19 a thousand times over a 19.0 that needs an emergency 19.1 two weeks later.

There's a less pretty side, of course. The cost of this cleanup falls on volunteers and on engineers paid by a handful of companies. Generating an automated report costs pennies. Analyzing each one costs hours of someone who could be writing features. If the community doesn't build filters, the risk is that maintainers burn out before the bugs run out.

And this isn't unique to Postgres. curl, Linux, OpenSSL and plenty of other projects have already complained about low-quality AI-generated reports. The difference here is that most of the findings seem legitimate. The problem isn't junk. It's volume.

What changes in your Postgres upgrade

In practice, if you use Postgres every day, the message is simple.

Don't plan your upgrade by the calendar date. If your team had "migrate to 19 in Q4" on the roadmap, revisit it. Wait for the release, and ideally wait for the first minor. That was always good practice. Now it matters even more.

Test the beta or RC against your workload. Nobody knows your queries better than you. Spin up a container and run your test suite against it:

docker run -d --name pg19 -e POSTGRES_PASSWORD=dev -p 5433:5432 postgres:19rc1
DATABASE_URL=postgres://postgres:dev@localhost:5433/postgres bun test

Adjust the tag to whatever test version is published. If something breaks, report it. Your report with a real reproduction is worth more than ten generic ones.

Keep an eye on minors for current versions. Many of these bugs aren't only in the new code. When a fix affects older versions, it gets backported to the minors from 14 to 18. So the next maintenance releases will probably be packed fuller than usual. Upgrading a minor is cheap and usually doesn't require pg_upgrade:

SELECT version();
-- PostgreSQL 18.1 ... so check whether a newer 18.x is out

If you use a managed database (RDS, Neon, Supabase, Cloud SQL), the minor usually arrives on its own during the maintenance window. Just make sure the window is configured and wasn't forgotten back in 2022.

What this teaches about your own code

There's a lesson here for any project, including that Node API you maintain on your own.

If AI tools can find bugs in Postgres, one of the most reviewed codebases in open source, they will find them in yours. That cuts both ways. You can use it in your favor before launch, or someone can use it against you afterwards.

Here's what I've been doing in my projects:

• run automated review on PRs, but treat the output as a suggestion, never as truth
• ask the tool to generate the test that reproduces the bug, not just a description of it
• only accept a finding after the test actually fails on my machine

That last point gets rid of most of the noise. A report without a reproduction goes to the back of the line. A report with a failing test becomes a priority. That's exactly the filter an overloaded maintainer needs.

The other lesson is about capacity. If your team starts using AI to review code, the number of problems found will go up. That doesn't mean the code got worse. It means you'll need time in the sprint to fix things. If you don't save that time, you build a pile of issues nobody looks at, and the tool becomes just another ignored alarm.

Is Postgres 19 worth the wait?

It is. And the wait itself is a good sign.

Postgres earned its reputation as the database that won't let you down precisely through choices like this one: holding the release instead of pushing code with known bugs. AI changed the pace of the hunt, but the review culture is still the same. If you store customer data, that's exactly what I want from a database.

The funny part is that after years of hearing AI would write all the software in the world, its first big contribution to Postgres was giving humans more work. At least it's the right kind of work.

I use Postgres in pretty much everything I build, and I'll wait for 19 calmly. If you want to see where it runs around here, take a look at my projects.

Postgres 19 is late, and the reason isn't a lack of code. It's too many bugs.

AI tools are finding problems in the Postgres codebase at a pace the community has never seen. And since the project doesn't ship features with known bugs, the schedule went out the window.

What struck me most: finding bugs got cheap, fixing them is still expensive. Reproducing, reviewing and making sure nothing else broke still depends on a small group of very experienced people.

To me, this is great news. Those bugs were already there. AI just turned on the lights before they showed up at 3 a.m. on your production server.

If your team starts using AI to review code, save time in the sprint to fix what it finds. Otherwise it becomes just another alarm nobody checks.

I wrote about what this changes for your upgrade and for your own code. The link is in the comments.

#PostgreSQL #ArtificialIntelligence #OpenSource #SoftwareDevelopment #Backend