Why PostgreSQL 19 is late: committer Robert Haas points to bugs found by AI

For the past 10 years, the PostgreSQL database has released a new version every year between mid-September and mid-October. Version 18 arrived on September 25, 2025. This year, however, version 19 has slipped into November. In an October 30 blog post, Robert Haas, a committer and core developer with permission to commit code to the repository, pointed to AI as the cause.

Haas cited commit counts as evidence. From the feature freeze on April 8 through September 25, the number of commits made only to the next development version fell slightly compared with last year. But commits also applied to the version being prepared for release rose from 724 last year to 1,169 this year, an increase of more than 60%. Fixes backported to the previous, already released version also rose from 248 to 433, an increase of more than 74%. Haas attributed this to a sharp rise in the number of people using LLMs to find and report bugs.

He also explained why the schedule had slipped. More bugs found means more time spent fixing them. LLMs sometimes draft fixes, but those fixes are not always correct, so people have to review them before they can be merged. Meanwhile, time that could have gone toward deciding what to remove before release had to be spent fixing security issues and bugs in earlier versions. Haas said this also explained why three major features were removed from 19 so late, between August 27 and September 15.

The PostgreSQL release team's announcement tells a similar story. When the team published the first release candidate on October 15, it said the routine updates scheduled for November 12 would contain a very large number of fixes. The team therefore decided to incorporate those fixes into 19 before releasing it, with a second release candidate also due that day. If no problems arise, general availability is planned for November 19.

This changes the question developers need to answer. So far, discussions of how AI will change software development have mostly focused on writing code faster. At PostgreSQL, however, finding bugs became much easier without a comparable improvement in fixing them, and fixes still needed human review. When only the cost of finding bugs drops sharply, the schedule becomes constrained by the time reviewers have available.

Teams therefore need to decide in advance how to handle incoming reports, rather than simply whether to use AI. They need to prioritize reports based on severity and whether the issue is a new regression or a longstanding defect. They also need to decide when to backport fixes to earlier versions and how much time to reserve for review before release. Haas predicted that every feature developed from now on would face AI scrutiny, and that mistakes that might once have gone unnoticed could surface within hours.

Still, it is too early to attribute all of these numbers to AI. Haas did not rule out the possibility that committers had made more mistakes this year. He said his bigger concern was not a delay of a few weeks, but how long it would take to catch up with bugs that had accumulated over 40 years and that humans had been unable to find.

AI has made bugs faster to find, but projects committed to maintaining quality need to budget time to fix and review them. There is one thing teams using PostgreSQL should do now. With a very large number of fixes expected in the November 12 routine updates, they should read the release notes for the version they use and plan when to apply the updates.

Sources

1. Robert Haas: Postgres 19 is late, and it's AI's fault, October 30, 2026. Originally published on the Neon blog.
2. PostgreSQL Global Development Group: PostgreSQL 19 RC 1 Released!, October 15, 2026.
3. PostgreSQL 18 release notes, released September 25, 2025.