PostgreSQL 19 Slipped as AI Bug Reports Outpaced Human Review
Robert Haas describes a release delayed by a larger supply of bugs and the human work required to fix them.
PostgreSQL’s bug finders got faster. The people deciding whether a proposed repair belongs in a database release still have to read it.
In his October 30 account, Haas expected version 19 in November, with further delay possible. He says three substantial features were reverted late in beta, calling it “unusual” to pull several major features that late. His explanation comes from inside the project; it isn’t an experiment that isolates AI’s contribution.
The workload jump is measurable in his chosen windows. From April 8 through September 25, he counted 724 commits on the upcoming release branch in 2025 and 1,169 in 2026. That’s about 61% more, with commits counting changes rather than individual bugs.
The reverted features make the delay concrete. Haas lists UPDATE/DELETE FOR PORTION OF, SQL property-graph queries, and partition merging and splitting. He places their reversions between August 27 and September 15, well after the April 8 feature freeze. A feature that appeared in beta could therefore disappear before the release an operator had been planning around.
His commit comparison separates work reaching the release branch from changes landing only on the development branch. The latter declined slightly in the windows he chose, while release-branch changes rose by more than 60%. Counting all development commits as new features would miss the maintenance effort he is describing. The extra activity was arriving precisely where the project needed to settle the release down.
Older supported code added another queue. Haas compares 248 commits to the previous-release branch in his 2025 window with 433 to the corresponding previous-release branch in 2026. That is about 74.6% more, calculated from his figures. Different changes can require different amounts of review, so these numbers describe activity rather than a stopwatch reading of the team’s workload.
The proposed fixes don’t remove that constraint. Haas says machine-generated patches can be incorrect or fail the project’s standards, leaving people to review and commit them. More reports can improve the eventual database while creating immediate competition between fixing known issues and checking features intended for the next version. The same person cannot review both at once, however impressively the incoming reports are formatted.
Haas treats the short delay as an expression of concern for quality. His larger worry is the backlog exposed by new ways of examining decades of code. An upgrade plan could accommodate a later date; a maintenance team still has to work out how discovery and verified repair stay close enough together.
Haas writes that AI-generated fixes “still need to be reviewed and committed by humans.” That is the awkward part of promising acceleration to everyone in the same queue.
Haas ends with the work he says he and others are trying to figure out: keeping innovation moving while catching up with defects that older tools missed. A future report measuring reviewer hours per confirmed issue would help show whether that work is getting easier.