The reverts will continue until morale improves
Short summary
PostgreSQL 19 saw an unusually high number of feature reverts during beta — around 8-10 major ones — largely because LLM-assisted code review is now catching edge cases and architectural issues that would have been discovered and fixed gradually over years in the past. A security crisis also pulled senior developers away during the critical beta review period, compressing the timeline to address problems.
- LLM-assisted code review is surfacing defects far faster than manual review ever did, creating a backlog of fixes that can't be completed in time; features written before this tool existed now face a higher quality bar retroactively.
- The "Vulnpocalypse" security event between April and August pulled experienced reviewers away during beta, delaying discovery of issues until late in the cycle when there wasn't enough time to fix them without missing the release date.
- PostgreSQL's design principle that "everything works with everything" — like features working across domains, composite types, partitions, views, and triggers in combination — creates exponential test complexity that manual testing can't handle but LLM fuzzing exposes instantly.
- The community is considering an "experimental" feature status to let complex features mature in the main tree rather than being reverted, which could have helped several of the affected features.
Full summary
PostgreSQL 19's beta period saw an unusually high number of feature reverts—around 8 to 10 significant ones—which is abnormal for a release cycle. Peter Eisentraut, who was directly involved with some of these reversions, breaks down what actually happened. It wasn't just bad code. Part of it was straightforward: developers tackled features that proved too complex to finish on time, or the code quality genuinely wasn't there. But the bigger story involves LLM-assisted code review fundamentally changing how problems get discovered. Features written years ago, before these tools existed, are now getting flagged for edge cases and architectural issues that would've surfaced gradually over five years in the past. Finding forty defect reports instead of three changes the calculus entirely—even if each fix is trivial, the cumulative overhead kills your timeline.
The timing made everything worse. The Vulnpocalypse (a major security incident) hit in April, right when feature freeze started, pulling senior developers away from the usual beta review and testing work until August. That's four months of reduced scrutiny, which meant problems piled up and got discovered late. The community chose to stick to the release schedule rather than delay, so reverts kept happening into late beta. There's also a structural problem with PostgreSQL itself: the system's promise that "everything works with everything" creates exponential complexity. A SQL feature needs to work with domains, composite types, dropped columns, table partitions, views, security-definer functions, triggers—the combinations are endless. Manual testing can't enumerate them all, but LLM fuzzing finds issues instantly. This quality bar has been permanently raised by tooling, but the code architecture hasn't adapted to support it.
Despite the reverts, PostgreSQL 19 will ship with solid features like concurrent REPACK, logical replication of sequences (itself a previously reverted feature that made it back), and planner hinting. The additional scrutiny means the release will be more robust. Looking ahead, the community is considering an "experimental" feature status that would let code mature in the main tree rather than getting reverted entirely. Several features are already 80% ready for PostgreSQL 20, so the momentum isn't actually lost—it's just shifted forward.