Postgres 19 Is Late, and It's AI's Fault
November 2, 2026, Morning
PostgreSQL 19 was supposed to ship by mid-October. It's November now, and the release still isn't out. The reason, according to PostgreSQL major contributor Robert Haas, is not bad management or feature creep. It's that LLMs got too good at finding bugs.
Over the past decade, Postgres releases followed a predictable cadence: mid-September to mid-October. This year, November is the earliest realistic target. Three major features, UPDATE/DELETE FOR PORTION OF, SQL Property Graph Queries (SQL/PGQ), and ALTER TABLE MERGE/SPLIT PARTITION, were reverted between August 27 and September 15, which is unusually late in the beta cycle.
The numbers tell the story. Between April 8 (feature freeze) and September 25, the master branch received 1'443 commits in 2026 versus 1'037 in 2025. But the real jump is in back-patches: 1'169 commits to REL_19_STABLE in 2026 versus 724 to REL_18_STABLE in 2025, a 60% increase. Back-patches to the prior release jumped 74% year over year.
Haas is clear about what he thinks happened. The committers weren't making more mistakes. The mistakes they did make were being found faster, by LLMs scanning the codebase. Finding bugs got easier. Fixing them didn't get easier at the same rate, so the backlog of fixes grew, and the release slipped.
This is a weird side effect of the AI coding boom. We talk about LLMs writing code, but here they're acting as the most relentless code reviewers in history. They don't sleep, they don't get bored, and they can hold an entire 30-year-old codebase in context. The Postgres codebase has always had bugs. What changed is that now there's something that can find them at scale.
There's a parallel to fuzzing here. AFL and libFuzzer transformed security research by making it cheap to find crashes. LLM-based bug finding is doing the same thing for logic bugs. The difference is that fuzzers find bugs by running the code, while LLMs find them by reading it. Both produce a flood of findings that humans then have to triage and fix.
The Postgres team will ship 19. It'll be later than usual, and it'll probably be more solid than usual because of all the extra bug finding. But the pattern is worth paying attention to. When finding bugs becomes nearly free, fixing them becomes the bottleneck. Open source projects that rely on volunteer committers are going to feel this pressure first, because their fixing capacity is the most constrained.
Haas doesn't suggest a solution, and there isn't an obvious one. You can't tell people to stop finding bugs. You can't magic up more committers. The release slips, and everyone accepts it, because a late release with fewer bugs is better than an on-time release with more. But at some point, the gap between finding and fixing has to close, or releases will keep getting slower.
Sources: