PostgreSQL 19, the next major version of the open source database most startups run, is late. The project reverted about 8 to 10 significant features during the beta, and general availability moved to November 19, according to the PostgreSQL 19 RC 1 announcement. The Register says it was once slated for late September or early October, so the Postgres 19 delay is somewhere around six weeks.
The part that interests me is the reason. Peter Eisentraut, a core committer, wrote that AI-assisted code review found bugs faster than the team could fix them. In this post I go over what he actually says, what I counted myself in the public git history, and what a small team like mine can take from it before running AI review on its own repos. My verdict: AI review is worth doing, but budget the fixing time first, because the finding is the cheap part.
What happened in the Postgres 19 delay?
Eisentraut explains it in a blog post called The reverts will continue until morale improves. He says some reverts are normal, “maybe one per cycle could be expected”. This time “about 8 to 10 significant features, depending on how you count” came out, some of them late in the beta. That count is his, not mine.
Looking at the REL_19_STABLE branch, I can name some of them from commit titles: SQL Property Graph Queries (SQL/PGQ), ALTER TABLE ... MERGE/SPLIT PARTITION, UPDATE/DELETE FOR PORTION OF, online data checksum transitions, GROUP BY ALL and the pg_get_*_ddl() functions. The reverted work is expected to go back toward PostgreSQL 20.
His list of causes is longer than “AI”. Some features had “significant architectural defects that would have been hard to fix quickly and during beta”. Senior developers spent April to August on security fixes, which he calls the Vulnpocalypse, so beta review was thinner than usual. And the community chose to hold the release schedule rather than delay for fixes. He says it is “probably a combination of these”, and “just my opinions”.
Did AI review cause the Postgres 19 delay?
This is the key passage, so I want to give it correctly. Before, many edge-case problems “would not have surfaced until much later and we would have fixed them bit by bit over the subsequent five years”. With LLM-assisted code review they surface fast, “and then you’re staring at a list of like forty defect reports”. Each fix might be three lines, but “there is a fixed overhead to dealing with each of these, and then you run out of time.”
Think about what that fixed overhead is. Someone reads the report, reproduces it, decides if it is real, writes the patch and a test, gets a review, and checks nothing else broke. Mettons two hours each, a number I made up. Forty reports is 80 hours, two full weeks of one senior person, and the senior people were already busy.
He also says the features were written before today’s tools were good, so “the effective quality bar has been raised after the time the feature was written and committed”. Same code, higher bar. That is why he says it is not vibe coding: this code is older than that habit.
He also thinks LLM-assisted fuzzing should become part of feature development, because “no one can manually test” every combination of domains, partitions and triggers that a new SQL feature must survive. I agree.
What does the Postgres git history show?
Bon. Quotes are one thing, so I counted, because a blog post is only a story until you open the log. I pulled the last 700 commits on REL_19_STABLE through the GitHub API (July 6 to October 16, 2026). These are my counts, from my own script, and they are not an official number.
- 14 commits start with “Revert”. 3 in July, 2 in August, 9 in September. Some are small, so this is not the same as Eisentraut’s 8 to 10 features. The last one landed September 16, and I saw no new reverts in the commits through October 17.
- 22 commits credit an AI tool in the message. I searched for Claude, Codex, OpenAI, Anthropic and “AI assisted review”. By month: 2 in July, 14 in August, 2 in September, 4 in October. My first pass said 23, but one match was the string “codeX” inside
DecodeXLogRecord, so I dropped it. People do not always credit the tool, so the true number is higher, and I cannot say by how much. - None of the 14 revert commits mention an AI tool. The AI credits are on fixes, not on the reverts.
The August spike is the interesting shape. Seven of the August 14 are dated August 10, and that day has 35 commits carrying a Security: line, which fits what Eisentraut says about the August security release. So much of the AI credit in Postgres right now is security reports, a separate thing from the beta bug list.
Do the later commits look like a long tail?
A bit, yes. These are closer to his “long tail”. Three commits, on September 28, October 8 and October 15, are credited to Bharath Rupireddy finding things with “AI assisted review”, all around parallel autovacuum, a new 19 feature. One of them fixes DROP DATABASE FORCE failing while a parallel autovacuum is running. The RC 1 notes list “several fixes for parallel autovacuum”, so this is a real stream of small fixes. Read the commit message and you see the cost: the author explains why it is only backpatched to v19, and what could go wrong if they guessed.
Another commit, on a hash index bug, says “Claude Code found this problem. The committed test case is a simplified version of the one that it wrote to demonstrate this bug.” That fix is backpatched through v14, so the bug sits in code that shipped years ago. Old code, new bar, exactly as Eisentraut describes. I like the detail that the model wrote a failing test, and a human shrank it.
I did not prove any of this caused any revert. The Register article does not name tools or give a bug total either, and I found no official count.
What does this mean for a startup using AI review?
Mettons you point a model at your own repo next week. You will meet what Postgres met: a pile of reports, many small and real, a few scary, some “technically true, who cares”. The model finishes in an afternoon and you owe the triage.
This is my plan, and I have not tested it at Trellis yet. First, ask the model for a failing test, not a report. The Postgres commits that read best all carry one, and a test either fails or it does not, which kills the “is this real?” meeting. Second, set the triage budget before you start, say one day a week, capped. Third, run it on new code first, because the Postgres reverts were old features judged by a new bar, and a short list is one you can finish.
Fourth, keep an “experimental” door. Eisentraut says the Postgres community has talked for a while about committing features with an experimental status and has not figured out how. A startup can do it with a feature flag tomorrow morning, and I would, for anything half-baked.
One fair counterpoint: does AI review find more bugs, or only find sooner the bugs people would have fixed over five years? Eisentraut’s own wording points to the second. For a team shipping next quarter, sooner is a bill you pay now. I wrote about a similar gap, a cap that needed a database behind it to work, and there too the finding was cheap and the closing was the work.
Should you upgrade to PostgreSQL 19?
Not on day one. The release team plans RC 2 for November 12, the same day as the next minor releases, and GA on November 19. Eisentraut says it will still be “a great release”, with REPACK CONCURRENTLY, logical replication of sequences and pg_plan_advice. I will test RC 1 on a copy of our data and read the open items page before touching anything real.
The number I am going to watch is how many of the reverted features are back in PostgreSQL 20. I will count again in the git log when that branch opens.
