PostgreSQL 19 release date moves to 19 November: what was cut, what shipped, and how to test the RC

PostgreSQL 19 will not ship in September or October like the last several major releases. The release team now plans general availability for 19 November 2026, after a second release candidate on 12 November (RC 1 announcement). Between eight and ten significant features were pulled out during beta, including SQL/PGQ graph queries, UPDATE/DELETE ... FOR PORTION OF, and MERGE/SPLIT PARTITION, and two committers have said publicly that LLM-assisted bug finding is a large part of why.

This article sorts out what that means if you run Postgres. You will get the dates, what was cut and why, what did make it into 19 (REPACK (CONCURRENTLY), WAIT FOR LSN, parallel autovacuum, sequence replication), the changed defaults and incompatibilities that will bite an upgrade, and the queries and commands to test your own cluster against RC 1 before GA.

When is PostgreSQL 19 released?

The planned date is Thursday 19 November 2026. The RC 1 announcement says RC 2 is needed because fixes due in the 12 November minor release were also taken into 19, and that GA follows a week later unless a problem requires another candidate. Release candidates are meant to be nearly identical to the final release, so RC 1 is the right build to test against now.

For comparison, Robert Haas notes that major releases over the past decade have landed between mid-September and mid-October (Haas). The full schedule is on the open items page.

Why Postgres 19 is late: more bugs found, the same number of people to fix them

LLMs made bugs easier to find, and fixing them still needs human review. That is the argument of Robert Haas, a PostgreSQL committer, in Postgres 19 is late, and it's AI's fault, and his numbers show where the time went: from feature freeze to late September, commits to the stable branches, which carry fixes rather than features, rose by more than 60 per cent on the new release branch and more than 74 per cent on the previous one.

"Release in progress" is REL_18_STABLE in 2025 and REL_19_STABLE in 2026; "previous release" is REL_17_STABLE and REL_18_STABLE. Haas reads the rise as bugs found faster rather than committers making more mistakes: people are reporting LLM-found bugs, including security issues, and committers have been fixing them. LLMs can draft fixes too, but those are not always correct or up to project standards, so a human still has to review and commit each one.

Eisentraut adds a second cause in his own post: senior developers spent April to August on security work, which cut into the usual beta review. He also says the reverted code was mostly written before "vibe coding" was possible, so this is not a story about AI-written patches. It is a story about AI-assisted review raising the cost of shipping a feature that has edge cases nobody had looked for.

Which features were removed from PostgreSQL 19?

Three large SQL features and several smaller changes were reverted after beta began; most are expected back in PostgreSQL 20. Haas names the three big ones and dates their reverts between 27 August and 15 September; the open items page lists the rest with their commits.

If you had written migrations against Beta 1 using any of these, they will fail on RC 1 with a syntax error or an unknown function. Tom Lane's earlier warning about SQL/PGQ, quoted by The Register, explains the bias towards reverting: "if we ship it in v19 there will be post-release bug discoveries that are unfixable until v20." A bug in new grammar or a new catalog representation cannot be fixed in a minor release without breaking dumps, so it waits a year.

What made it into PostgreSQL 19

The operational features survived, and several of them remove reasons to run extensions or downtime windows. The release notes list the full set; these are the ones most teams will use first.

REPACK (CONCURRENTLY) replaces VACUUM FULL and CLUSTER

REPACK rewrites a table to reclaim space, optionally in index order, and with CONCURRENTLY it keeps the table readable and writable for most of the run. VACUUM FULL and CLUSTER remain for compatibility. The REPACK reference describes the mechanism: the bulk of the work runs under SHARE UPDATE EXCLUSIVE, concurrent changes are captured through logical decoding, and ACCESS EXCLUSIVE is taken only to swap the files at the end.

-- Rebuild a bloated table online and refresh its statistics afterwardsREPACK (CONCURRENTLY) orders;ANALYZE orders; -- Watch progress from another sessionSELECT * FROM pg_stat_progress_repack;

The restrictions matter. CONCURRENTLY refuses partitioned, unlogged and non-heap tables, tables without a primary key or index-based replica identity, and cannot run inside a transaction block; it needs a free slot under max_repack_replication_slots; and it fails if more than about 104 million rows are updated or deleted during the run. It also is not MVCC-safe: a transaction whose snapshot predates the repack sees the table as empty after it commits. You need free disk equal to the table plus its indexes (REPACK).

WAIT FOR LSN gives read-your-writes on replicas

Write on the primary, take the LSN, and make the replica wait until it has replayed that far before you read. Before 19 this meant polling pg_last_wal_replay_lsn() in application code (WAIT FOR).

-- On the primary, after the write commitsSELECT pg_current_wal_insert_lsn();   -- e.g. 0/306EE20 -- On the replica, before the readWAIT FOR LSN '0/306EE20' WITH (TIMEOUT '200ms', NO_THROW);-- returns success, timeout or 'not in recovery'

WAIT FOR must be a top-level statement: not inside a function or DO block, and not while a snapshot is held, which rules out REPEATABLE READ transactions. It compares LSNs only and ignores timelines, so after a failover check the timeline yourself.

Autovacuum, replication and COPY

• Parallel autovacuum of indexes, capped by autovacuum_max_parallel_workers and set per table with autovacuum_parallel_workers; tables are now prioritised by score, visible in pg_stat_autovacuum_scores.
• Logical replication of sequences with CREATE PUBLICATION ... FOR ALL SEQUENCES and ALTER SUBSCRIPTION ... REFRESH SEQUENCES, which removes a classic manual step from logical-replication upgrades.
• Logical replication without a restart when wal_level is replica; the new read-only effective_wal_level shows what is actually in force.
• pg_plan_advice and pg_stash_advice to pin planner decisions, the latter applied automatically by query ID.
• COPY ... TO ... (FORMAT json), which since RC 1 uses the query's column names and aliases as keys.

What breaks when you upgrade to PostgreSQL 19

Most clusters upgrade cleanly, but several defaults changed and a few old configurations are refused outright. These come from the "Migration to Version 19" section of the release notes.

Two of these silently change behaviour rather than failing. With JIT off, an analytical query that relied on it simply gets slower. And a pre-19 dump from a server with standard_conforming_strings = off loads with wrong string contents, so always dump with the new version's tools.

How to test your database against PostgreSQL 19 RC 1

Run the three checks below on your current cluster, then a pg_upgrade --check against an RC 1 install. The project asks for beta and RC testing and takes reports through its bug form.

-- 1. btree_gist inet/cidr indexes: pg_upgrade to 19 refuses theseSELECT i.indexrelid::regclass AS index_name, o.opcnameFROM pg_index iJOIN pg_opclass o ON o.oid = ANY (i.indclass::oid[])WHERE o.opcname IN ('gist_inet_ops', 'gist_cidr_ops'); -- 2. Roles still on MD5 passwords (run as a superuser)SELECT rolname FROM pg_authid WHERE rolpassword LIKE 'md5%'; -- 3. Databases in an encoding that 19 removesSELECT datname FROM pg_databaseWHERE pg_encoding_to_char(encoding) = 'MULE_INTERNAL';

Then point pg_upgrade from the RC 1 binaries at a copy of your data directory with --check, which runs the compatibility checks without changing anything (pg_upgrade). Paths depend on your packaging; these are the Debian and Ubuntu layout.

/usr/lib/postgresql/19/bin/pg_upgrade \  --old-bindir /usr/lib/postgresql/18/bin \  --new-bindir /usr/lib/postgresql/19/bin \  --old-datadir /var/lib/postgresql/18/main \  --new-datadir /var/lib/postgresql/19/main \  --check

Run your application's test suite against the RC 1 server too, with JIT left at its new default, and compare query plans for your heaviest reports. If something regresses, there is still time to report it before GA; after 19 November it waits for a minor release at best.

The one thing to remember: PostgreSQL 19 is a release with fewer headline SQL features and more scrutiny than any before it. Plan the upgrade around REPACK, the changed defaults and the refused configurations, not around features that are now scheduled for 20.

Sources and further reading

• PostgreSQL: 19 RC 1 announcement, PostgreSQL 19 release notes, 19 Open Items, beta testing
• Documentation: REPACK, WAIT FOR, pg_upgrade, upgrading a cluster
• Robert Haas, Postgres 19 is late, and it's AI's fault, 30 October 2026
• Peter Eisentraut, The reverts will continue until morale improves, 9 October 2026
• The Register: Postgres 19 delayed after AI reviewers find more bugs than humans can fix and the September report on SQL/PGQ