Postgres 19 is late, and it's AI's fault
B · Useful, limited A first-hand account by Robert Haas, a long-standing PostgreSQL committer, with commit counts anyone can check in the public git history; the causal link to LLM bug reports is his judgement, and one sentence contradicts his own figures.
Summary based on the full text·Original: about 5 minutes to read
In short
A blog post (30 October 2026, first published on the Neon blog) by Robert Haas, a PostgreSQL major contributor and committer. PostgreSQL major releases have shipped between mid-September and mid-October for a decade; version 19 will probably slip to November. Three large features were pulled late in beta. Haas's explanation: people across the internet are finding bugs with LLMs and reporting them, committers are busy fixing them, including in older releases, and review time for the new release ran short. Finding bugs got much easier; fixing them got only a little easier.
Key numbers
- 724 ... 1169commits to the new stable branch between feature freeze and 25 September, 2025 against 2026
- more than 60%rise in back-patched commits to the release in progress
- 248 ... 433commits back-patched to the previous stable branch in the same window, 2025 against 2026
- more than 74%rise in commits back-patched to at least one earlier release
- 1037 ... 1443commits to the master branch in the same window, 2025 against 2026
As reported by the source.
English·Web page·opens rhaas.blogspot.com
What it reports
- Late reverts between 27 August and 15 September: UPDATE/DELETE FOR PORTION OF, SQL Property Graph Queries (SQL/PGQ), and ALTER TABLE MERGE/SPLIT PARTITION. Feature freeze was 8 April.
- From feature freeze to 25 September, commits to the new stable branch rose from 724 (2025) to 1169 (2026), "more than 60%".
- Commits to the previous stable branch in the same window rose from 248 to 433, "more than 74%", meaning more fixes back-patched to releases already in use.
- Haas attributes the rise to LLM-found bug reports, not to committers making more mistakes.
- LLMs draft fixes, but these are not always correct or up to project standards, so humans still review and commit every one.
- His long-term worry: forty years of bugs that humans missed but LLMs can find, and how the project keeps innovating while catching up.
How they got it
Counts of commits by branch and date range from the project's git history, with the author's interpretation as a committer. No breakdown of how many reports came from LLM-assisted finders.
Limits
- Causation is the author's judgement; commit counts do not show who found each bug or how.
- Text and numbers conflict: Haas says master-branch commits "declined slightly", but his own figures show 1037 rising to 1443.
- One project, one year-on-year comparison.
- No figures on security issues specifically, though he says back-branch time went to them.
Why it matters for companies
Most firms run software built on open-source projects like PostgreSQL. If maintainers spend more time on a flood of LLM-found bugs, releases slow, more fixes land in old versions, and patch volume rises for operators. Two practical points follow: budget more time for applying minor-version updates, and expect the same rise in findings against internal code once anyone points a model at it. The bottleneck is human review capacity, not detection.
Summary based on the full text. Read the original for the full argument and data.Read the original on rhaas.blogspot.com