Postgres 19 delayed after LLM code review flagged 8 to 10 features

Teams that run a long branch and merge at the end are now carrying risk that was not there when the branch was opened. Peter Eisentraut, a PostgreSQL committer and VP at EDB, wrote on his blog on 9 October that about 8 to 10 significant features have been reverted from PostgreSQL 19 after the beta began, and he put most of the blame on LLM-assisted code review finding problems in work that had already been committed.

The release itself is pushed back. The Register reported on 16 October that PostgreSQL 19 is now expected around 19 November instead of late September or early October. The post itself does not name the new date, so treat the November figure as The Register's. Eisentraut's post names three features that stayed: REPACK CONCURRENTLY, logical replication of sequences (which he notes was itself a previously reverted feature), and planner hinting through pg_plan_advice. He does not name the features that were reverted.

What Eisentraut said about the mechanism

The quote that matters sits in one sentence: "with LLM-assisted code review, these kinds of things can get found much faster, and then you're staring at a list of like forty defect reports." He frames the effect as a bar that keeps moving: "the effective quality bar has been raised after the time the feature was written and committed." Most of the reverted features were written before LLM-assisted review was in practice, so by the time reviewers ran these tools, the standard the code had to meet was higher than it was at commit time.

He also writes that this was not about generating code: the reverts were not caused by vibe coding during development. His framing is that detection improved, not that the code got worse.

The context of the April to August gap

Eisentraut names a second cause. Senior developers were occupied with security fixes between April and August 2026, a period he calls the Vulnpocalypse, which took reviewer attention away from the beta. The usual pace of beta review was interrupted, so defects that would have surfaced earlier arrived in a bunch. The LLM review and the review gap worked together.

What he thinks happens next

Two sentences from the post set the forecast. "Unless the capabilities of LLM-assisted code review keep improving at the current rate, this situation should sort itself out for future development cycles." And "PostgreSQL 19 will still be a great release." Both are his words, both are forward-looking, and neither is a measurement.

The consequence for a team that is writing software this week is simpler than the Postgres case. If a code review tool today reads work that was committed last year, the author of that work is not in the review and often cannot be. A long branch, a stalled fork, a dormant library and an acquired codebase all now hold latent defects that nobody is on the hook to fix. Budget review time for your own old code, not only for the new changes you ship.

Source

Peter Eisentraut, The reverts will continue until morale improves. The Register, Thomas Claburn, Postgres 19 delayed after AI reviewers find more bugs than humans can fix.