A PostgreSQL release cycle normally reverts maybe one feature. The 19 cycle has reverted eight to ten significant ones, some quite late in the beta period, and Peter Eisentraut, who developed or committed several of them, has written the post I would hand to anyone shipping software that now gets read by machines. His short accounting: the code didn’t get worse; the review got better.

He is careful that this not become a single-cause story: probably a combination, he says — maybe the code wasn’t good enough, maybe a coincidence of features that turned out too hard to finish — with a different mix per reverted feature. The entry that generalizes is the LLM-assisted review one. It is about a long tail of relatively harmless edge-case issues, the kind that in past cycles would have surfaced in production over the following five years and been fixed bit by bit; review now finds them during beta, all at once: “then you’re staring at a list of like forty defect reports. And even if each of them requires only a three-line fix on average, there is a fixed overhead to dealing with each of these, and then you run out of time.” The features were written years before review could read at this level, so the effective quality bar was raised after the code was committed. He rules out the fashionable explanation himself: this is not vibe coding, and the code predates it. He expects it to partly self-correct — new features will be written under review that can already read them — but any project carrying a pre-LLM-era backlog has the same wave coming.

The economics underneath are simple and not PostgreSQL-specific. When finding a defect was slow, the long tail stayed latent and production paid for it in small installments. When finding became nearly free, the same tail arrived as one invoice inside the freeze window, and the cost moved to the receiving end, where it is paid per report: someone has to triage it, reproduce it, verify it, and commit the three-line fix — a fixed overhead per report, however small the fix is. curl is the same ledger with the opposite entry: Aisle’s year of pointing AI tooling at curl produced thirty-five published CVEs, “more CVEs in curl than any other group or individual ever did before,” and Daniel Stenberg is grateful, because curl pays the receiving end deliberately, with skilled humans verifying the findings and shipping fixes at a rate the project had never reached. PostgreSQL 19’s beta paid the same invoice by reverting features instead.

The community-scale version of the transfer sat on Terence Tao’s blog the same week, as satire: generating “things that look correct” amounts to “outsourcing the tedious, unprestigious, and unprofitable work of determining the actual correctness and understanding to the mathematics community.” The kernel’s maintainers spent their October summit on the inverse question, how to count AI assistance at all. The bottleneck moved from finding to absorbing, and nobody’s calendar grew.

Eisentraut’s prescription is the part worth copying outside databases: move the finding upstream. The interaction space he gives as an example — a query-language feature that has to work with domains, over composite types, with a not-null constraint, on a column that was dropped and re-added, inside a partition that was detached and reattached with a different column order, called from a security-definer function in a trigger — is one “no one can manually test or even enumerate these test cases. But LLM-assisted fuzzing can find problems with this really quickly. So this probably needs to be part of feature development in the future.” Finding during development puts the fixed overhead where there is calendar for it; finding during beta puts it where there isn’t. He also floats committing features with an “experimental” status to mature in-tree, something the PostgreSQL community has contemplated but not figured out.

He is candid about the confounds: the Vulnpocalypse kept senior developers on security fixes from April to August, so the extra beta review that normally catches things early happened late, which is why the reverts clustered late; and the community preferred sticking to the release schedule to delaying for more fixes. He still expects 19 to be a great release — REPACK CONCURRENTLY and logical replication of sequences ship — and the forecast he drops in passing is the one I would keep: a few months ago he predicted PostgreSQL 20 might be bug fixes only, and 19 now has “kind of” half the expected major features, with “a few nice 80%-ready features queued up for PostgreSQL 20 that just need those remaining 80% to get done!”

Every count and quote here is his or Stenberg’s. I did not audit PostgreSQL 19, count reverts, or re-run any of Aisle’s findings, and the Vulnpocalypse’s effect on the beta window is his inference, not a measurement.