PostgreSQL core committer Robert Haas published a blog post on October 30 explaining why this year's major release is late. For the past decade, PostgreSQL major versions have shipped between mid-September and mid-October, but PostgreSQL 19 will most likely slip to November, and the project could push it back further. His explanation comes down to a single line:
"The short answer is that LLMs happened."
Haas is now a senior principal software engineer at Databricks. The post reflects his own judgment, and he did not offer a new release date.
Three major features pulled in the final month
The feature freeze falls on April 8 every year, and pulling features after the freeze is nothing unusual. What stands out this year is the timing and the weight: between August 27 and September 15, three major features were reverted one after another.
UPDATE/DELETE FOR PORTION OF- SQL property graph queries (SQL/PGQ)
ALTER TABLE ... MERGE PARTITION / SPLIT PARTITION
According to Haas, features get reverted in other years too, but rarely this late and rarely several big ones at once.
Commits are up by more than half, and committers have not gotten sloppier
He fixed the comparison window at April 8 to September 25 each year and compared the volume of fixes. Last year 724 commits landed in REL_18_STABLE; this year 1,169 landed in REL_19_STABLE, an increase of more than 60%. For the previous stable branch, REL_17_STABLE received 248 commits last year versus 433 for REL_18_STABLE this year, a rise of more than 74%.
Haas does not think the extra commits mean people are writing worse code. He judges that committers are about as careful as in previous years; what has changed is the discovery stage. Many people now use LLMs to hunt for PostgreSQL bugs and report them directly.
"What's different now is that it's become vastly easier to find those bugs."
There is a gap in this attribution. Commit logs do not record who found a bug or with what tool, and the post does not say what share of reports came from LLMs. The increases above are measured figures; "mainly because of LLMs" is the observation of a veteran committer.
The bottleneck is human review
The delay works on two levels. First, more bugs means more time spent fixing them. LLMs can draft patches, but a patch is not necessarily correct or in line with project conventions, and a committer still has to review each one before it is merged. The second level is less visible: time that should have gone into reviewing the contents of the new release has been eaten up by security issues and defects in older branches, which in turn delayed the decision on which features to revert.
It is worth reading this alongside the Firefox experiment Epoch AI published a few days ago. Epoch measured the attack side: using GLM 5.3 to write exploits within the window after a patch becomes public, at roughly $1,000 of compute per version. Haas describes the maintenance side: the same capability applied to a decades-old project makes report volume climb first, while the number of people able to review code does not climb with it. The variable common to both is the cost of finding vulnerabilities, which has fallen faster than the cost of fixing them.
This is not distant for teams in China either. Many cloud database products are built on PostgreSQL derivatives, so if upstream backports rise by 60% to 70%, the workload of following those patches downstream may grow accordingly. How large the effect is, no vendor has yet put a number on.
Forty years of backlog is the long-term pressure
Haas is not alarmed by the delay itself. He says that over the long run it is not much of a slip, and that it stems from the project's insistence on quality. He also stresses that the problems AI has found have not changed his view of the quality of the codebase.
What leaves him uneasy is what comes next. The project has accumulated roughly forty years of bugs that no human found, and LLMs can dig up many of them; in his words, "how are we ever going to catch up." From now on every new feature will be reviewed by AI, which is both a pressure and a chance to make the code sturdier. He offers no solution, saying only that he and many others are working on one.
The final date for PostgreSQL 19 will depend on what the release team announces next.
Sources: Robert Haas's personal blog; CocoLoop; Epoch AI's public experiment report; branch commit figures follow the method given in Haas's post and were not independently recalculated.