PostgreSQL 19 slips to November 19 after reverting 8-10 features; committers debate AI review's role

PostgreSQL 19 loses major features and slips to November

PostgreSQL 19 will reach general availability on November 19, 2026, according to the project's first release candidate announcement on October 15 — several weeks later than the late-September or early-October window The Register reported on October 16 as the original plan. The candidate announcement says the date holds unless a new issue forces a delay or a second release candidate.

The slip follows an unusually heavy round of removals. Committer Peter Eisentraut wrote on October 9 that roughly eight to ten significant features, depending on how you count, had been reverted from the release. A Snowflake engineering post by developer advocate Elizabeth Garrett Christensen on September 16 counted 53 reverts in total since the beta began, with the larger user-facing ones including SQL Property Graph Queries (SQL/PGQ), ALTER TABLE ... MERGE/SPLIT PARTITION(S), UPDATE/DELETE ... FOR PORTION OF, GROUP BY ALL and online data checksums.

What survived, and what comes next

According to Eisentraut, notable features still in PostgreSQL 19 include REPACK CONCURRENTLY, logical replication of sequences and pg_plan_advice, and the RC1 notes list fixes since Beta 4 for parallel autovacuum and COPY (query) TO with JSON output. He expects many of the reverted features to return, which puts PostgreSQL 20 as the earliest landing spot.

The Register reports that SQL/PGQ, part of the SQL standard since 2023, was pulled over unresolved issues, and that committer Tom Lane said in September he would bet dinner that shipping it in version 19 would produce post-release bugs that could not be fixed until version 20.

The AI-review explanation

Eisentraut's post does not name a tool or model; his argument is about timing. LLM-assisted review now catches architectural defects, plus a long tail of smaller edge cases, faster than review did when the features were written — so the effective quality bar rose after the code was already committed, and every finding carries fixed handling overhead. He explicitly rules out "vibe coding," noting the affected code predates that practice. He also gives a second cause: what he calls the Vulnpocalypse, which kept senior developers occupied with security fixes from roughly April to August instead of beta testing and review.

The Snowflake post put AI closer to the center, saying AI has to be part of the story, and noted that PostgreSQL currently has no official AI contribution policy, though one is expected soon.

The backlog counter-explanation

Committer Tomas Vondra audited the mailing-list threads behind 12 reverts dated May 20 to September 16 and checked, for each, whether AI had found the problem. His summary: only four rated as probably or definitely AI. PostgreSQL consultant Christophe Pettus points out that the per-revert verdicts are stingier than that headline — one scored AI, one possibly AI, and two probably not.

Vondra instead blames review that arrived late. Plotting commits whose subject begins with "Revert" across the development cycle, he found the PG19 reverts spiking around day 430, well after the feature freeze near day 275 and just before releases that usually land near day 480. On the cause, he cites security work: roughly five CVEs last year against 44 already this year, which he calls one of the primary reasons for reduced review activity during stabilization.

Pettus's verdict is that the reverts were not a case of AI finding unfixable bugs. AI did appear in the process — Vondra mentions reviews done with Opus 4.8 and Opus 5, and Claude use in a couple of threads — but Pettus writes that committer Noah Misch dismissed three of the four findings in the commit he reviewed with a model, with the revert there stemming from Misch's own design judgment. Pettus's framing is that filtering the findings is itself the review. Both camps describe the same mechanism — review came late, then found more than the project could fix before release — and disagree on how much of it a model produced.

What users should do

The project's beta testing guidance says candidate releases are not meant for production, and the Snowflake post recommended PostgreSQL 18 as the safe upgrade target for now. RC1 is still a good testing point: running pg_upgrade --check with the 19 binaries against a copy of your data flags compatibility problems without modifying anything. Upgrade plans that counted on GROUP BY ALL, SQL/PGQ or the partition merge and split commands should be pushed to a later version.

Why it matters

For any team with a review bot attached to its pull requests, the mechanics here will look familiar: findings are cheap to generate, but each one still needs a person to read it, decide, and own the answer. The transferable lessons are to run the expensive review before merge rather than during stabilization, and to budget real capacity for triage. The episode also leaves open-source projects with a policy question PostgreSQL has not yet written down — assisted use may be fine, but a human should remain accountable for every verdict. Meanwhile, the November 19 date and the missing features ripple outward to the huge number of products and distributions that build on Postgres.