PostgreSQL 19 has slipped by roughly a month, and the reason says a lot about how AI is changing open source maintenance. The release, once expected in late September or early October, is now targeted for around November 19, with between eight and ten significant features pulled and pushed to PostgreSQL 20. Early coverage blamed LLM code review for surfacing more defects than humans could fix in time. Committer Peter Eisentraut pointed at a long tail of edge-case issues that LLM-assisted review surfaced fast, turning a trickle into a list of forty defect reports, each cheap to fix but expensive to triage.
Committer Tomas Vondra then went through the history of all twelve reverts of major features and challenged the viral version. In only four of the twelve cases was the problem found by AI. The other eight came from ordinary human review by long-time maintainers, and the number of revert commits this cycle is not unprecedented against a larger commit volume. The real AI effect, he argues, is indirect and quieter: a flood of security reports, some machine generated, that lands on senior reviewers exactly during the stabilization window. PostgreSQL CVEs jumped from around five in 2025 to 44 in 2026, with 28 arriving in the August patch alone.
Vondra calls the pattern AI inversion. Generation scales automatically, but triage throughput does not, so the bottleneck moves to the humans who read and rank reports. For founders building on Postgres, the practical outcome is a date shift: the release lands about a month late and features such as SQL/PGQ, MERGE and SPLIT PARTITION, and GROUP BY ALL wait for PostgreSQL 20. The wider lesson applies to any team shipping AI-generated code or bug reports: tooling that multiplies output without multiplying review capacity just moves the queue. Budget reviewer time, or the release calendar pays for it.