On August 25, Robert Haas opened a pgsql-hackers thread like this:
I asked Claude to evaluate which v19 patches were the scariest based on the number and type of bugs fixed post-freeze. Results below, with a few particularly cutting remarks from the LLM edited out.
The subject line was “scary patch contest.” Six patches made the list. Within three weeks, four of them had been reverted out of PostgreSQL 19, and the release had slipped from the usual late-September GA to October 29.
I mention this because there is a story going around that AI is happening to the PostgreSQL project, arriving from outside as a wave of generated patches that the committers are heroically holding back. That is not what the record shows. The tools came in through the front door, carried by the most senior people in the project, and they are being used in public, on the list, on the most consequential decisions of the cycle. Noah Misch had Opus 5 review the CREATE SCHEMA object-type expansion. Andres Freund posted an AI review of SQL/PGQ alongside his own. Haas used an LLM to rank the release’s riskiest commits and then asked thirty of his colleagues what to do about it.
For a project that still does code review over SMTP, that is a remarkable amount of adoption in about eighteen months.
The reverts were not AI finding unfixable bugs
Tomas Vondra published an analysis on October 1 that is the most useful thing written about this release cycle, and it exists because the first draft of the story was wrong. A Snowflake engineering post by Elizabeth Garrett Christensen on September 16 put it this way:
AI has to be part of the story for why we’re in this situation. Several folks are using AI tools to find bugs and create valid reproducible test cases. The fixes are fairly large, so pushing to a future version makes the most sense for many of these features.
Vondra went through the reverts one at a time and the claim does not survive. Online data checksums: no AI in the issues that mattered, reverted because too many post-commit problems arrived too late. UPDATE/DELETE FOR PORTION OF: a human review by Andres, concurrency behavior the authors already knew about and had documented a workaround for. pg_get_role_ddl() and friends: Noah’s human review of dependency handling, then Andres on permissions and locking. SQL/PGQ: two human reviews by Andres, after Haas flagged it. ALTER TABLE ... MERGE/SPLIT PARTITION: a regular review by Zsolt Parragi, on a feature that had already been committed and reverted once in the PG17 cycle. Database-specific logical replication snapshots: Amit Kapila and Andres.
His summary says four of the twelve reverts he examined came out “probably AI” or “AI.” His own per-revert verdicts are stingier than that: one is scored AI, one possibly AI, and two probably not. The single clear case is the CREATE SCHEMA expansion, and it is worth looking at closely, because it is the best example anyone has of these tools being used well.
Noah ran Opus 5 over commit d516974. The review’s most important finding was not in d516974 at all; it was in a sibling commit, a9c350d, which had deleted setSchemaName() so that a new schema reached its own elements only through a prepended search_path entry. The consequence is that in PG18 a view created inside CREATE SCHEMA binds to the new schema’s table, and in PG19 it binds to public. The review quoted ISO/IEC 9075-2 5.4 SR 4)b) verbatim to argue that PG19’s interpretation is not permitted.
Then Noah went through the four findings in the commit he had actually asked about and dismissed three of them. One was a restatement of an old psql parsing bug. Two he declined to act on. One he accepted as a real but unconcerning bug. And then he wrote the paragraph that actually carried the revert, which was his own: that CREATE SCHEMA ... CREATE buys modest benefit, handicaps the parser for every command it supports, and risks painting the project into a corner.
So: a tool produced a large report, most of which was noise, containing one finding the reviewer recognized as serious, which prompted a design judgment that no tool made. Haas did the same thing in miniature when he deleted the LLM’s cutting remarks and dropped its runners-up before posting. The filtering is the review. Strip it out and you have a mailing list full of plausible text and nobody accountable for any of it.
The actual mechanism is the CVE queue
Vondra’s second finding is better than his first, and almost nobody has picked it up. He counted reverts per development day back to PostgreSQL 14 and PG19 is unexceptional. What changed is when. In previous cycles reverts cluster right after feature freeze, around day 300. For PG19 that bump is missing entirely; there is a flat line and then a spike at day 430, in early September. Review did not increase. Review happened late.
Why it happened late is the part that should worry you. The project’s security page currently lists 44 CVEs for 2026. Last year it was about five. The August 2026 PG18 update release alone carried 28. Those reports do not triage themselves, and the people who triage them are the same two dozen people who do post-commit review of committed features during stabilization. Spend that pool on security reports in July and August and the design problems in SQL/PGQ get found in September instead of April.
That is a far less flattering mechanism than “AI found bugs too hard to fix,” and it is the one with evidence behind it. It is also the thing Vondra predicted in February, in The AI inversion: these tools make producing a patch, a review, or a vulnerability report dramatically cheaper, and do close to nothing for the person who has to evaluate it. Review capacity is the scarce resource in this project and always has been. Anything that multiplies inbound volume without multiplying that capacity is a tax, whatever its average quality.
Note the asymmetry he draws, because it is the useful one. You can ignore a patch. You cannot ignore a review; the custom on -hackers is to answer every point, which means a generated review with six irrelevant findings obligates a contributor to write six rebuttals. curl hit the same wall from the security side and stopped taking vulnerability reports for a month.
PostgreSQL has no AI policy. It should.
As of this writing there is no official policy on AI use in PostgreSQL contributions. Jan Wieremjewicz at Percona counted the projects that do have one in June: CPython, Django, the Linux kernel, LLVM, Kubernetes, NumPy, SciPy, PyTorch, Flutter, Homebrew, CloudNativePG, and roughly a dozen more. They converge on the same shape. Assisted use is fine. AI as the contributor is not. The human reviews and owns the result.
Write that down. Three things belong in it:
Disclose the tool, in the message. Haas and Noah both did this voluntarily and it cost them nothing. It is also the only reason we can have this argument with evidence instead of vibes; Vondra had to infer tool use from thread archaeology, and he says plainly that undisclosed use would have skewed his count.
Own every point you post. If you have not reproduced it, verified it against the code, and decided it matters, delete it. This is the rule Noah followed when he threw away three findings out of four, and the one that distinguishes his message from slop.
Reviews get the stricter rule, not patches. This is where the current guidance in other projects is weakest and where Postgres has the chance to be specific. A bad patch wastes the author’s time. A bad review wastes a reviewer’s time and conscripts the patch author into answering it.
None of this changes your upgrade plan. RC1 is scheduled for October 15, GA for October 29, and PG18 remains the right production target until then. What it changes is what you should believe when someone tells you AI delayed PostgreSQL 19. It did, just not in the direction anyone claimed, and not by writing a single line of the code that got reverted.