Postgres 19 is late, and it's AI's fault · Robert Haas, Databricks, PostgreSQL major contributor and committer · rhaas.blogspot.com, October 30, 2026 (the post says it first appeared on Neon's blog)
LLM-found bugs drove a 60% jump in PostgreSQL back-patches and a late Postgres 19
Machine-readable
Download Markdown
Haas writes that PostgreSQL major releases have landed between mid-September and mid-October for a decade, and that 19 is likely to slip to November or later. Three large features were reverted between August 27 and September 15: UPDATE/DELETE FOR PORTION OF, SQL Property Graph Queries (SQL/PGQ), and ALTER TABLE ... MERGE PARTITION/SPLIT PARTITION. His diagnosis: "The short answer is that LLMs happened."
His evidence is commit counts from the project's git history, covering April 8 to September 25 in each year. Commits to the release branch in progress rose from 724 (REL_18_STABLE, 2025) to 1,169 (REL_19_STABLE, 2026), which he calls a jump of more than 60%. Commits back-patched to the previous release went from 248 (REL_17_STABLE, 2025) to 433 (REL_18_STABLE, 2026), more than 74%. We leave out his master-branch comparison, because the numbers he gives for it do not match his description of them.
The causal story is Haas's own inference. He says the committers were probably no less careful than before and that "a lot more of the mistakes they made were quickly found by LLMs," with outside reporters now filing bugs they found using LLMs. Two effects follow, in his account: LLMs can draft fixes, but those fixes are not always correct or compliant with PostgreSQL standards, so humans still review and commit them; and review time that would have gone to the release went to security issues and bugs in the back branches, which is why he thinks the late reverts happened. He does not call the delay worrying. He calls the long-term picture "less clear and in some ways more troubling" and says he does not yet know how the project catches up on forty years of bugs that LLMs can now find.
Why it matters: Haas's account puts the bottleneck in reviewed fixes, not in finding bugs. If outsiders can point LLMs at your codebase, expect the inbound defect rate to rise faster than your review capacity, and plan maintainer time for back-branch work before the next release rather than after.