PostgreSQL 19 RC1 Is Out, With GA Now Set for Nov 19

PostgreSQL 19 RC1 shipped on October 15, and the schedule changed: the release team added an RC2 on November 12 and moved general availability (GA) to November 19. If Postgres sits under your retrieval-augmented generation (RAG) store, often with pgvector, rehearse the upgrade in staging now. The deadline that actually binds you is PostgreSQL 14's end of life, a week before GA.

PostgreSQL 19 release date: RC2 added, GA moved to November 19

In an October 10 note to pgsql-hackers, the release team said RC1 stays on October 15 and GA moves to November 19, one week after the scheduled update release. The back branches (the supported older versions) collected a large number of fixes, and the team wants them in a PostgreSQL 19 RC2 on November 12 before GA.

The RC1 announcement adds the usual caveat: GA holds unless an issue forces a delay or another release candidate.

What changed between beta 4 and PostgreSQL 19 RC1

The announcement is a fix list, not a feature list. Since beta 4 it names, among others:

• Several fixes for REPACK (CONCURRENTLY) and for pg_plan_advice.
• Fixes for planner optimizations that depend on whether an expression can be NULL.
• Fixes for the automatic enablement of logical replication when wal_level is replica.
• Fixes for parallel autovacuum.

Nothing there mentions vectors, so treat a pgvector database as an ordinary upgrade test, not a new-feature story.

PostgreSQL 14 end of life is the real deadline

PostgreSQL supports a major version for five years, then ships a final minor release. For 14, the versioning policy lists that final release as November 12, 2026, the same day as RC2. After it, 14 is unsupported.

GA lands a week later, so waiting for 19.0 means a week on an unsupported version. My pick for anything that can't wait is 18, supported through November 14, 2030. Move to 19 if your rehearsal comes back clean.

Rehearse a pg_upgrade to PostgreSQL 19 in staging

RC1 is not an in-place upgrade from earlier versions. The announcement says to use a major version upgrade strategy such as pg_upgrade or pg_dump / pg_restore, and the upgrade docs also list logical replication. Restore a production backup to a staging host, install the RC1 binaries, then run:

<new-bin-dir>/initdb -D <new-data-dir>

# dry run: checks both clusters, changes nothing
pg_upgrade \
  -b <old-bin-dir> -B <new-bin-dir> \
  -d <old-data-dir> -D <new-data-dir> \
  --link --jobs=4 --check

# real run: same command without --check
# then rebuild planner statistics, as the pg_upgrade docs describe
vacuumdb --all --analyze-in-stages --missing-stats-only --jobs=4
vacuumdb --all --analyze-only --jobs=4

The --check pass catches blockers such as indexes pg_upgrade refuses to carry over. Match initdb options (locale, encoding) to the old cluster.

Then read the beta release notes migration section, which may still change before GA. Items worth testing against your app:

• JIT is now off by default.
• max_locks_per_transaction defaults to 128, up from 64.
• json_array() returns an empty array instead of NULL when no rows match.
• Dumps taken with standard_conforming_strings = off won't load properly into 19.

Test REPACK CONCURRENTLY on your most bloated table

REPACK replaces VACUUM FULL and CLUSTER (the old commands remain). With CONCURRENTLY, the REPACK docs say the bulk of the work runs under a SHARE UPDATE EXCLUSIVE lock, with ACCESS EXCLUSIVE held only for the final file swap.

-- needs a primary key or index-based replica identity;
-- not for partitioned or UNLOGGED tables, or inside a transaction block
REPACK (CONCURRENTLY, VERBOSE) <your_table>;

-- from another session: REPACK counts as one long transaction
SELECT pid, backend_xid, state, query
FROM pg_stat_activity
WHERE query ILIKE 'REPACK%';

Gotchas from the docs: it needs a free slot under max_repack_replication_slots, it is not MVCC-safe for snapshots taken before it started, and DDL on the table can make it fail. While it runs, VACUUM can't clean dead rows in other tables.

Check pgvector and your retrieval queries after the upgrade

I found no official pgvector statement of PostgreSQL 19 support, so confirm a build exists for your platform. pg_upgrade wants extension libraries installed for the new server (don't run CREATE EXTENSION yourself) and writes a script for available extension updates.

SELECT extname, extversion FROM pg_extension WHERE extname = 'vector';

EXPLAIN (ANALYZE, BUFFERS)
SELECT id FROM <your_chunks_table>
ORDER BY embedding <=> '<query-vector>'
LIMIT 10;

Run a fixed set of real queries on old and new, then compare recall against exact search and p95 latency.

What to do on Monday morning

1. List every cluster by major version and flag the 14s.
2. Run the pg_upgrade --check rehearsal against a restored copy.
3. Run your app tests and the retrieval comparison.
4. Calendar November 12 (RC2 and the last 14 release) and November 19 (GA).

For anyone serving RAG from Postgres, the support clock, not the release candidate, decides when you upgrade, so rehearse now while the surprises are cheap.