Postgres 19 Is Late, and One of Its Developers Blames Bugs Found by AI. In the Same Months of 2025 and 2026, Fixed Vulnerabilities Rose From 4 to 39; an AI Is Credited on 9

In March 2023 a company that backs up its PostgreSQL database from a replica wrote to the project’s bug list: some of its backups could not be restored, because a row that another table pointed to was missing. Peter Geoghegan, one of the database’s developers, answered the same day that he had heard internal reports of similar symptoms in other setups and “never got to the bottom of the problem despite spending some time on it.” On 26 August 2026 the fix went in, with Geoghegan as first author. The commit message says: “Claude Code diagnosed this problem.” The test that ships with it is “a simplified version of the one that it wrote to demonstrate this bug.” The cause was an oversight in a change from 2017, and the fix was carried back to every supported version, down to PostgreSQL 14.

Episodes like this are what Robert Haas, a PostgreSQL committer who works at Databricks, has in mind in “Postgres 19 is late, and it’s AI’s fault”, published on Neon’s blog on 21 October and reposted on his own blog on 30 October. For a decade, he writes, major versions have arrived between mid-September and mid-October; version 19 “most likely won’t be released until November”. Three large features were pulled from it between 27 August and 15 September. On 10 October the release team moved general availability to 19 November, after a second release candidate on 12 November, “given the volume of fixes that have been added to the back branches”.

Haas’s evidence is a count. Between feature freeze on 8 April and 25 September, the maintenance branch of the previous release received 248 commits in 2025 and 433 in 2026, an increase he puts at more than 74%. His explanation is that “a huge number of people on the Internet are now reporting bugs in PostgreSQL that they found using LLMs”; committers, he thinks, were no sloppier than usual, but “it seems likely” that many more of their mistakes “were quickly found by LLMs”. Fixing has become easier too, he adds, but not to the same degree, and the long view worries him: “given that we have forty years of bugs that humans were unable to find but LLMs are quite capable of discovering, how are we ever going to catch up”.

We recounted from the project’s public git history, using commit dates in the same window. The previous-release branch goes from 249 commits in 2025 to 436 in 2026, up 75%, within three of Haas’s figures. The rise also shows on the branch of PostgreSQL 14, released in 2021: from 145 to 244. Commits that credit someone with reporting the problem went from 92 to 191, and the distinct names in those credits from 82 to 141. The sharpest jump is in security: on the previous release’s branch, commits marked with an official vulnerability identifier covered 4 vulnerabilities in the 2025 window and 39 in 2026. The 39 are exactly those fixed in the May and August updates; the August one alone, the project announced, “fixes 28 security vulnerabilities and over 110 bugs”. The project’s security page lists 7 vulnerabilities with 2025 identifiers and 44 so far with 2026 identifiers.

What the history says about AI is narrower. In the 2025 window, no commit on these branches mentions an AI model, company or tool, as far as our search terms can tell. In 2026, 16 of the 436 commits on the version 18 branch do. Fifteen credit a model or an AI lab with finding, diagnosing or analysing a problem: “Reported-by: Claude Code (via Noah Misch)” four times, the two notes saying that Claude Code found or diagnosed the problem, three credits to “Ben Morris in collaboration with Claude and Anthropic Research”, three to “Amy Burnett (OpenAI Codex Security)”, one fix authored by the “OpenAI Security Research Team”, one analysis by a developer “using claude”, and one report from Calif.io “in collaboration with Claude and Anthropic”. The sixteenth says that initial drafts of the patch were made with Claude Opus 4.8: help with writing, not with finding.

Thirteen more commits credit “Xint Code” and say nothing else about it. Its makers describe it as “a fully autonomous AI-powered security analysis tool”; in February the project had already fixed a heap buffer overflow it found in an encryption extension, in code added in 2005. Counting Xint Code, 28 of the 436 fixes, about one in sixteen, credit an AI as finder or analyst. At the level of vulnerabilities, 9 of the 39 have at least one fix that does. The other credits name people and companies, and leave the method unsaid: one August vulnerability, a buffer overflow in the formatting function to_char, carries eleven different reporters in its fixes, among them OpenAI’s Codex Security.

So the record bears out the part of Haas’s account that can be counted: in one year the fixes, the reporters and above all the vulnerabilities rose sharply, and the first explicit AI credits appeared in the same year. Whether most of the new reports came from language models, as he believes, the record cannot show. Credit lines are voluntary and there is no field for how a bug was found; several reporters work at security firms that sell AI-based tools, but the commits do not say so, and we did not count them. Haas’s exact date convention is not stated, so our figures differ from his by up to three commits, and we did not recount his figures for the branch of version 19. Commits are not bugs: maintenance branches also receive documentation, test and release-note changes. Our search for AI mentions relies on names and keywords and may miss paraphrases, and Xint Code is counted as AI only on its makers’ description. The 19 November date is a plan, not a release.