Postgres 19 Rolls Back Nearly Ten Features: Is AI Code Review the Driver or the Scapegoat?

A Rollback Sparks a Debate Over Attribution

PostgreSQL 19's release cadence has been disrupted. According to committer Peter Eisentraut in an October 9 blog post, "roughly 8 to 10 significant features, depending on how you count" have been rolled back from PostgreSQL 19. The Register confirmed in an October 16 report that the original late-September or early-October release date was pushed back, and the October 15 RC1 announcement set general availability (GA) for November 19, with the caveat "unless issues are found that require a delay or an additional release candidate."

What really made this go viral was one of the reasons Eisentraut gave: LLM-assisted code review is finding problems faster than before, "which means the effective quality bar was raised after features were written and submitted." That line was extracted into headlines and subsequently drew rebuttals from another group of Postgres developers. If your team also has a review bot attached to every PR, the focus of this debate lands squarely on your review queue too.

The Rollback List: What Left, What Stayed

Elizabeth Garrett Christensen, a developer relations engineer at Snowflake, tallied in a September 16 engineering blog post that PG19 had accumulated 53 rollbacks since the beta phase began, and listed the larger user-visible features among them.

The heavyweight features removed include: SQL property graph queries (SQL/PGQ), ALTER TABLE ... MERGE/SPLIT PARTITION(S), UPDATE/DELETE ... FOR PORTION OF, GROUP BY ALL, and online data checksums. The Register noted that SQL/PGQ was pulled due to unresolved issues—the feature has been part of the SQL standard since 2023. Tom Lane said in September he "would bet a dinner" that if v19 shipped it anyway, the resulting production bugs would not be fixed until v20.

The features that stayed are equally worth noting. Eisentraut named REPACK CONCURRENTLY, logical replication of sequences, and pg_plan_advice. The RC1 release notes also list fixes to REPACK (CONCURRENTLY) and pg_plan_advice since Beta 4, as well as parallel autovacuum and COPY (query) TO ... (FORMAT json). Eisentraut expects many of the rolled-back features to return, but not until PostgreSQL 20 at the earliest.

SQL/PGQ (SQL Property Graph Queries) is a property graph query extension introduced by the SQL:2023 standard, allowing MATCH pattern queries to be written directly against a graph model of vertices and edges over relational tables, without an additional graph database. For PostgreSQL, this means adding a graph pattern parser, a path-matching executor, and catalog metadata—far beyond ordinary syntactic sugar. It has been eagerly anticipated since becoming a standard in 2023, but its implementation complexity and numerous corner-case semantics make it exactly the kind of object Tom Lane worried would "have bugs dragging into v20 if shipped anyway."

REPACK CONCURRENTLY is a long-missing operational capability for PostgreSQL: traditional VACUUM FULL or CLUSTER holds an exclusive lock and blocks reads and writes, whereas REPACK aims to rewrite tables and reclaim space online. Its survival in 19 is a substantive boon for production environments that need to control table bloat.

AI Raised the Bar: One Explanation

Eisentraut's blog did not name any tool or model; it discussed the overall phenomenon of LLM-assisted code review, and his argument rests on timing. Review now catches architectural-level defects that are hard to fix during the beta phase, plus a long list of corner-case issues, and "there is a fixed cost to addressing each one." He explicitly denied that this was caused by "vibe coding," because the affected code predates that practice.

In the same article he gave a second reason. Because of what he called the "Vulnpocalypse," many senior developers were busy with security fixes rather than beta testing and review between April and August.

Snowflake's September article put AI more at the center: "AI has to be part of the story that explains the current situation." It also noted that "PostgreSQL currently has no official AI contribution policy, but one is expected soon."

The "Vulnpocalypse" is the PostgreSQL community's nickname for the concentrated outbreak of security vulnerabilities in 2025. The article mentions roughly 5 CVEs last year versus 44 this year; the jump in magnitude means committers must spend substantial time on security assessment, patching, and coordinated disclosure—and these are precisely the people who are the main force behind beta testing and code review. Security fixes have hard time pressure, while beta review is relatively elastic, so review gets systematically deferred. This background matters: it suggests the rollback wave may not stem from "AI finding more problems," but from "human review being pushed to the very end of the release cycle." The two explanations overlap heavily on the timeline, and rollback counts alone cannot distinguish them.

Late Human Review: Another Explanation

Another committer, Tomas Vondra, took a more empirical path. He combed through the mailing-list discussions behind 12 rollbacks between May 20 and September 16, verifying case by case whether the problem was found by AI. His conclusion was: "Only 4 were classified as 'possibly AI' or 'AI.'" PostgreSQL consultant Christophe Pettus further pointed out that Vondra's case-by-case determination is stricter than that headline: one judged as AI, one possibly AI, and two probably not.

Vondra's explanation is a review backlog. He plotted the distribution of commits starting with "Revert" against development cycle days: feature freeze is around day 275, general release is usually around day 480, and PG19's rollbacks spiked around day 430. As for why review came so late, he pointed to security work: "Last year we had about 5 CVEs; this year we're already at 44." He called this "one of the main reasons for the decline in review activity during the stabilization period."

Pettus's judgment was: "The rollbacks are not AI finding unfixable bugs." AI did appear, through senior contributors and public mailing-list threads. Vondra's article mentions reviews done with Opus 4.8 and Opus 5, and the use of Claude in a few threads. Pettus wrote that Noah Misch rejected three of the four findings in the submission he reviewed with the model, and the rollback came from Misch's own design judgment. Pettus's summary of this was: "The filtering is itself the review."

The two camps' mechanical descriptions are actually consistent: review came late, and when it came, it found more problems than the project could fix before release. The only disagreement is how much of that was found by the model.

"The filtering is itself the review" points to the real workflow of AI-assisted review: the findings a model produces are often mixed with false positives and overreach, and senior committers must judge each one—which hold, which are design trade-offs, and which reflect the model misunderstanding the context. Noah Misch rejecting three of four findings shows that the model's value is not in its accuracy rate, but in putting candidate problems in front of a human who completes the screening and characterization. This is why the attribution debate easily distorts: counting by "whether a rollback was triggered by AI" understates AI's role; counting by "whether a model was used in review" overstates it. A more reasonable measure is the proportion of model findings that, after filtering, actually changed design decisions.

Three Migration Takeaways for Ordinary Teams

You may not maintain a database, but your PRs may already have a review bot attached. Three points transfer directly.

Put expensive review before merge. Eisentraut's core observation is that the quality bar moved after features were submitted. On an open PR, a finding is just a comment; the same finding after code is merged can cost a rollback.

Budget for triage. "There is a fixed cost to addressing each one" applies equally to your team. A reviewer that produces more findings than anyone can read is just lengthening the queue.

Every judgment needs a human owner. Pettus hopes PostgreSQL will write down the shape other projects' AI policies already share: "Assisted use is fine; AI as a contributor is not. Humans review and own the result." One of the rules he proposed is shorter: "Own every opinion you ship." Misch rejecting three of four model findings is exactly that rule at work.

If Your Upgrade Plan Is Scheduled for October

The plan needs to change. PostgreSQL's official beta testing page states that beta and release candidate versions are "not for production systems," and Snowflake's September article recommends PostgreSQL 18 as the safe upgrade target at this stage.

RC1 is a good time to test. Use the pg_upgrade binary from the 19 version $NEW_BIN to run --check on a copy of the data and a freshly initialized 19 cluster; it only performs compatibility checks and does not modify 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 depends on GROUP BY ALL, SQL/PGQ, or the partition merge/split commands, take them off the 19 plan. The beta testing guide on the wiki explains how to report findings, and the open items list shows what is still being fixed.

This debate over attribution ultimately points to a more mundane fact: the cost of finding problems has fallen to near zero, but the cost of reading, judging, and taking responsibility for conclusions has not. Review bots do not solve the latter; they merely expose it more clearly.

pg_upgrade --check only verifies compatibility between the old and new clusters—including directory structure, data types, collations, and extension versions—without migrating data or modifying the original cluster, so it can be safely run repeatedly on a copy of the data. It cannot replace a real upgrade rehearsal: actually running pg_upgrade also requires weighing link mode versus copy mode, migrating large objects and pg_statistic, and accounting for post-upgrade ANALYZE time. For teams planning to move to 19, it is advisable to first use --check to rule out hard incompatibilities, then run a full upgrade on a non-production copy and verify key queries, and only then schedule a production window.