PostgreSQL 19 slips to November, and a core developer blames LLM-found bugs

Serguey Asael Shinder31 October 2026, 10:242 min read

For a decade PostgreSQL major releases have landed between mid-September and mid-October. PostgreSQL 19 will not. In a post dated 30 October (https://rhaas.blogspot.com/2026/10/postgres-19-is-late-and-its-ais-fault.html), long-time committer Robert Haas writes that the release will most likely come in November and that a further postponement is not ruled out.

His numbers come from the project's own git history. In the window from 8 April, the feature freeze, to 25 September, the master branch received 1,037 commits in 2025 and 1,443 in 2026. Commits to the release branch being stabilised rose from 724 for version 18 to 1,169 for version 19, so back-patched work grew by more than 60% while work on master after the freeze actually fell slightly. Commits to the previous stable branch also jumped, from 248 to 433, more than 74%. Between 27 August and 15 September three large features were pulled from the release: UPDATE/DELETE FOR PORTION OF, SQL property graph queries and ALTER TABLE MERGE/SPLIT PARTITION.

Haas's explanation is that committers did not become careless; rather, many more people now report bugs they found with LLMs, in new code and in code decades old. Models can draft fixes, he writes, but the drafts are not always correct or up to project standards, so humans still review and commit every one. Time that would have gone into reviewing what was about to ship went instead into back-branch security and bug fixes, which is why the reverts came late.

He calls the delay itself unconcerning and the long-term picture "less clear and in some ways more troubling": forty years of bugs that humans missed are now discoverable, and the project has to keep innovating while working through them.

What it means

The post puts numbers on something many maintainers describe only anecdotally: the bottleneck has moved from finding defects to reviewing fixes. For users of PostgreSQL the practical consequence is more frequent minor releases on the stable branches, which carry these fixes and are worth applying. For other projects, the counts give a baseline to compare against. Haas's attribution is his judgement as an insider, not a measured split of reports by origin.