PostgreSQL 19 has shed roughly 8 to 10 significant features during its beta period, an unprecedented volume of reverts for a project that typically sees maybe one per cycle. Peter Eisentraut, a core developer and committer on the receiving end of several reverts, has published a candid post-mortem. The picture that emerges is not one of declining code quality but of a quality-assurance regime that suddenly became far more powerful than the development process was built to handle. The central mechanism is LLM-assisted code review and fuzzing. PostgreSQL's defining promise — "everything works with everything" — means that any new SQL feature must survive a combinatorial explosion of interactions: domains over composite types, dropped-and-readded columns, detached partitions called through security-definer triggers. No human can enumerate these cases. But LLMs can generate them fast, and they did, surfacing long tails of 40+ defect reports per feature. Each fix might be three lines, but the overhead per report is fixed, and developers ran out of calendar. Critically, most of the reverted code predates vibe coding entirely. These features were written when LLM review was less capable. The effective quality bar was retroactively raised after the code was already committed. This is a genuinely novel dynamic in open-source development: the review tooling improved faster than the codebase it was reviewing, creating a temporal mismatch between when code was written and when it was judged. The problem was compounded by the Vulnpocalypse — a wave of security vulnerabilities that consumed senior developer bandwidth from April through August 2025, precisely overlapping with the feature-freeze and beta-testing window. The usual additional review during beta was delayed, issues piled up late, and the community chose to stick to the release schedule rather than extend it. The reverts clustered at the end, making the situation look more dramatic than a steady trickle would have. Eisentraut identifies a structural deficit: PostgreSQL lacks an "experimental" feature status that would let incomplete work mature in-tree rather than face a binary ship-or-revert decision. The community has been discussing this for some time but hasn't settled on a mechanism. Several reverted features might have survived under such a regime. This is a governance gap, not a technical one. PostgreSQL 19 still ships with REPACK CONCURRENTLY, logical replication of sequences, and planner hinting via pgplanadvice. Eisentraut notes that the reverted features are mostly 80% ready and are queued for PostgreSQL 20, needing "the remaining 80%" — a joke that captures the nonlinear cost of combinatorial correctness. The project's culture of correctness remains intact; it just got stress-tested by its own new tools. The broader lesson extends well beyond PostgreSQL. Any mature codebase with deep combinatorial surface area — compilers, databases, operating system kernels — faces the same dynamic as AI-assisted review tools improve. The quality bar is no longer set by the humans who wrote the code or even the humans who review it. It's set by the tooling, and that tooling is on a steeper improvement curve than the development process itself. Projects that don't adapt their governance (experimental flags, extended beta windows, automated regression scaffolding) will face similar revert crises.
