PostgreSQL 19, the next major version of one of the most used databases, is now due on November 19, 2026. The roadmap had planned it for September. Headlines say AI code review caused the delay by finding more bugs than humans could fix. The truth is more mixed. A leading committer says AI review played a part. But the release team gave a different reason, and an independent analysis suggests AI explains only a few of the reverts. This article separates what is confirmed from what is argued.
What Is Confirmed
On September 28, the release team said the first release candidate (RC1) would come on October 15, with general availability on October 29. On October 10, it moved general availability to November 19. It added a second candidate, RC2, on November 12, so that a large number of fixes in older branches could be included. It called this an "atypical" cycle. The message does not mention AI.
Many features were also pulled. Peter Eisentraut, a PostgreSQL core team member at EDB, wrote on October 9 that about 8 to 10 significant features were reverted after beta began. Two are public. SQL/PGQ, which adds graph queries, was removed on September 7, taking out 47 commits. Committer Alexander Korotkov reverted ALTER TABLE MERGE/SPLIT PARTITION from the PostgreSQL 19 release branch on August 27, according to the project's pgsql-committers list. His commit message cites "multiple design issues" that were too late to address in this release cycle.
What Eisentraut Says AI Did
Eisentraut says some reverted features had architectural flaws that could not be fixed quickly during beta. But he also describes a long tail of mostly harmless edge-case bugs. In the past, many would have surfaced years later and been fixed bit by bit. With LLM-assisted code review, he writes, they surface fast, and "you're staring at a list of like forty defect reports." Each might need a three-line fix. But every fix has fixed overhead, and the project ran out of time.
He adds that most reverted features were written when AI review was less useful, so the effective quality bar rose after the code was committed. He says the reverts are not from vibe coding. In effect, review made hidden quality debt visible. He expects the problem to settle in future cycles unless AI review keeps improving at its current pace.
The Case That AI Is Only Part of the Story
Not everyone agrees. PostgreSQL consultant Christophe Pettus, who writes the blog The Build, summarizes an October 1 analysis by PostgreSQL developer Tomas Vondra. This is Pettus's account, since Vondra's post itself was not read. Vondra went through the reverts one by one. Most were driven by human reviews or known concurrency issues. Pettus counts one clear AI case, the CREATE SCHEMA change, where, he writes, Noah Misch ran Opus 5 over a commit. According to Pettus, Misch dismissed three of the review's four findings on that commit, and the revert rested on his own design judgment.
For SQL/PGQ, Pettus says two human reviews by Andres Freund drove the removal. In a September mailing-list thread, developers argued it needed rework and agreed to pull it from version 19. Freund also posted an AI review.
Pettus adds a second finding. The number of reverts per development day was not unusual. What changed was timing. Reverts usually cluster soon after feature freeze, and this time they came in September. Pettus links that to security work. Snowflake reports that PostgreSQL used to average a couple of CVEs per release, but the August 2026 update for PostgreSQL 18 alone carried 28. The same senior reviewers handle both jobs. This is Pettus's reading of the data. The release team has not endorsed it.
Why This Is Not an AI Junk-Report Story
This is not a flood of AI junk reports. Senior committers ran the tools, disclosed it, and filtered the output. In an August 25 pgsql-hackers post titled "scary patch contest," Robert Haas said he asked Claude to rank the riskiest PostgreSQL 19 patches and edited out some of its cutting remarks before posting. Pettus puts it this way: "The filtering is the review." Pettus says PostgreSQL has no official AI contribution policy, and Snowflake wrote in September that one is expected soon.
What Could Come Next
In the near term, RC2 arrives on November 12, and version 19 on November 19. PostgreSQL's versioning policy sets November 12 as the final release date for version 14, after which it is unsupported. Developers said the reverted features would be easier to fix properly in version 20.
The long-term picture is speculation. If AI review keeps improving, projects may need triage rules, disclosure policies, and more reviewers to turn cheap findings into fixes. The lesson is that finding defects has become cheap. Deciding which ones matter has not.
