PostgreSQL 19 was supposed to ship in late September. It didn’t. RC1 landed on October 15, general availability is now scheduled for November 19, and a Postgres committer just published a post explaining exactly why: AI-assisted code review is surfacing bugs faster than volunteers can fix them. The delay isn’t an engineering failure. It’s a new scaling problem the entire open-source world is about to inherit.
Robert Haas, a Postgres committer at Databricks, wrote “Postgres 19 is late, and it’s AI’s fault” on October 21. The numbers in the post are worth sitting with: back-patched commits to the PostgreSQL 19 stable branch jumped from 724 to 1,169 compared to the same point last year — a 60% increase. LLMs surfaced roughly 40 defect reports during the beta window, described as “relatively harmless issues involving various edge cases.” Harmless enough to ship with? Apparently not.
The real bottleneck isn’t the bugs themselves. LLMs can draft fixes. The bottleneck is that every AI-generated fix still needs a human committer to review it against PostgreSQL’s standards. The volunteer pool hasn’t scaled with the AI tooling. The Hacker News discussion framed it correctly: AI is improving the quality of Postgres faster than the project’s capacity allows. That’s a different problem than “AI delayed a release.”
What Got Cut #
Three headline features were reverted between August 27 and September 15, deferred to PostgreSQL 20:
- SQL/PGQ — property graph query support (CREATE PROPERTY GRAPH, GRAPH_TABLE) was reverted on September 7. If you’ve been watching this for graph use cases, don’t build against it yet.
- UPDATE/DELETE FOR PORTION OF — temporal query extensions for time-ranged updates.
- ALTER TABLE MERGE/SPLIT PARTITION — DDL for partition management.
Eight to ten features total were reverted across the full beta window. PostgreSQL 19 still ships roughly 200 new features, but the marquee items got cut. The right framing: this is a quality hold, not a project failure.
What IS Shipping #
The headliner is REPACK CONCURRENTLY. For years, dealing with table bloat meant either a VACUUM FULL (full table lock, nothing writes) or installing the third-party pg_repack extension. PostgreSQL 19 brings REPACK into core with a concurrency-safe option:
-- Old approach: ACCESS EXCLUSIVE lock, writers blocked
VACUUM FULL bloated_orders;
-- PG19: reads and writes continue during rebuild
REPACK (CONCURRENTLY) bloated_orders;
The numbers matter. REPACK CONCURRENTLY generated 18.8 GB of WAL and finished in 107 seconds on a 60-million-row table. pg_repack generated 33.5 GB and took 162 seconds. If you’re running pg_repack today, this is your migration target once you upgrade. One caveat: REPACK CONCURRENTLY fails if more than roughly 105 million rows are updated or deleted during the run — a fix is planned for PG20.
The other additions worth enabling after upgrade:
- Parallel autovacuum : opt-in via
autovacuum_max_parallel_workers. Off by default. Enable it and watch vacuum times drop ~23% on large tables. - WAIT FOR LSN : read-your-writes consistency on replicas. A session waits until a specific log position is replayed before querying — eliminates a whole class of distributed read-after-write bugs.
- Logical replication without restart : toggle wal_level to replica without taking the server down.
- pg_stat_lock : a new view surfacing per-lock-type statistics. Long overdue for anyone who’s tried to diagnose lock contention from pg_locks alone.
What Developers Should Do Now #
RC1 is available. If you have a staging environment, test against it now — the release notes are detailed. GA is November 19, following RC2 on November 12.
Before upgrading, check two breaking changes that pg_upgrade will block on: database or role names containing line breaks, and btree_gist indexes on inet or cidr columns. Both are edge cases but worth a quick audit before you start.
The AI QA scaling problem Haas described isn’t going away. More capable models, more codebases using them, same finite pool of expert reviewers. PostgreSQL’s response — delay the release, hold the quality bar — is the right call for a database. Other large open-source projects haven’t made that call yet.