- Book: AI Agents Pocket Guide
- Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go
- My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
- Me: xgabriel.com | GitHub
"About 8 to 10 significant features, depending on how you count, have been reverted" from PostgreSQL 19, committer Peter Eisentraut wrote on October 9. One reason he gives is LLM-assisted code review, which finds defects much faster than before, "meaning that the effective quality bar has been raised after the time the feature was written and committed."
The schedule moved too. PostgreSQL 19 was originally slated for late September or early October, The Register reported on October 16. The project's RC1 announcement on October 15 now plans general availability for November 19, 2026, "unless an issue is discovered that requires a delay or an additional release candidate."
The line about review became the headline. Other people who work on Postgres read the same revert history and came to a different answer. If a bot reviews your pull requests, the disagreement is about your queue too.
What left PostgreSQL 19, and what stayed
On September 16, a Snowflake engineering post by developer advocate Elizabeth Garrett Christensen counted 53 PG19 reverts since beta began and listed the bigger user-facing features among them. Some of the larger ones:
- SQL Property Graph Queries (SQL/PGQ)
ALTER TABLE ... MERGE/SPLIT PARTITION(S)UPDATE/DELETE ... FOR PORTION OFGROUP BY ALL- online data checksums
The Register reports that SQL/PGQ, part of the SQL standard since 2023, came out over unresolved issues, and that Tom Lane said in September he would "be willing to bet dinner" that shipping it in v19 would produce post-release bugs that couldn't be fixed until v20.
What stays: Eisentraut names REPACK CONCURRENTLY, logical replication of sequences and pg_plan_advice as notable features still in 19. The RC1 notes list fixes since Beta 4 for REPACK (CONCURRENTLY) and pg_plan_advice, plus parallel autovacuum and COPY (query) TO ... (FORMAT json). Eisentraut expects many of the reverted features to return, which means PostgreSQL 20 at the earliest.
Several of PostgreSQL 19's biggest features came out of the branch before RC1. The release still stands on the ones that stayed.
The case that AI review moved the bar
Eisentraut's post doesn't name a tool or a model. It talks about LLM-assisted code review in general, and his argument is about timing. Review now catches architectural defects that are hard to fix during beta, plus a long tail of smaller edge-case issues, and "there is a fixed overhead to dealing with each of these." He's explicit that the situation "is not due to 'vibe coding'", since the affected code predates that practice.
He gives a second reason in the same post. Because of what he calls the "Vulnpocalypse," many senior developers were busy with security fixes from roughly April to August, instead of beta testing and review.
Snowflake's September post put AI closer to the center: "AI has to be part of the story for why we're in this situation." It also noted that "PostgreSQL currently has no official AI contribution policy, though one is expected soon."
The case that it was late human review
Tomas Vondra, another committer, went through the mailing-list threads behind 12 reverts dated May 20 to September 16 and checked, for each one, whether AI had found the problem. His summary: "only 4 came out at 'probably AI' or 'AI'." Christophe Pettus, a PostgreSQL consultant, points out that Vondra's per-revert verdicts are stingier than that headline: one scored AI, one possibly AI, two probably not.
Vondra's explanation is a review backlog. He plots commits whose subject starts with "Revert" by day of the development cycle: feature freeze sits around day 275, releases usually land around day 480, and the PG19 reverts spike around day 430. On why review came so late, he points at security work: "Last year we had maybe 5 CVEs, this year we're already at 44." He calls that "one of the primary reasons for the lower review activity during the stabilization period."
Pettus's verdict: "The reverts were not AI finding unfixable bugs." AI did show up, through senior contributors and in public threads. Vondra's post mentions reviews done with Opus 4.8 and Opus 5, and Claude use in a couple of threads. Pettus writes that Noah Misch dismissed three of the four findings in the commit he reviewed with a model, and that the revert came from Misch's own design judgment. His line for it: "The filtering is the review."
Both camps describe the same mechanism: review came late, and when it came, it found more than the project could fix before release. They disagree on how much of that a model found.
A finding is cheap to produce. Someone still has to read it, decide, and own the answer.
What to take from it if your team runs AI review
You probably don't maintain a database, but you may have a review bot on every pull request now. Three things carry over.
Run the expensive review before merge. Eisentraut's point is that the quality bar moved after features were committed. A finding on an open PR costs a comment. The same finding after the code has merged can cost a revert.
Budget for triage. "A fixed overhead to dealing with each" applies to your team too. A reviewer that produces more findings than people can read just lengthens the queue.
Keep a human as the owner of every verdict. Pettus wants PostgreSQL to write down the shape other projects' AI policies already share: "Assisted use is fine. AI as the contributor is not. The human reviews and owns the result." One of the rules he proposes is shorter still: "Own every point you post." Misch throwing out three of four model findings is that rule at work.
What to do about your Postgres upgrade
If you planned a PostgreSQL 19 upgrade for October, move it. The project's beta testing page says beta and release candidate releases "are not meant for use in production systems," and Snowflake's September post recommended PostgreSQL 18 as the safe upgrade target for now.
RC1 is a good time to test, though. Point pg_upgrade --check at a copy of your data and a freshly initialized 19 cluster, using the 19 pg_upgrade binary from $NEW_BIN. It checks the clusters for compatibility without changing any data:
pg_upgrade --check \
--old-bindir "$OLD_BIN" \
--new-bindir "$NEW_BIN" \
--old-datadir "$OLD_DATA" \
--new-datadir "$NEW_DATA"
Then read the PostgreSQL 19 release notes against the list above. If your plan counted on GROUP BY ALL, SQL/PGQ or the partition merge and split commands, take them out of the 19 plan. The wiki's beta testing guide explains how to report what you find, and the open items list shows what is still being fixed.
Does your team's AI reviewer produce more findings than anyone reads? Tell me in the comments.
If this was useful
A review bot on every PR is an agent with a human approval step, and this story is what happens when that step falls behind. The AI Agents Pocket Guide covers the patterns for giving agents autonomy with guardrails, including where the human stays in charge of the result. I also build Hermes IDE, a source-available desktop app where you review each coding agent's changes turn by turn before you land them (GitHub), so weigh that mention accordingly.
Top comments (0)