PostgreSQL 19 Release Candidate: Upgrade Planning and What Changes

PostgreSQL 19 reached its first release candidate on 15 October 2026. The project plans a second candidate on 12 November and general availability on 19 November, unless an issue forces a delay. On 12 November, PostgreSQL 14 also stops receiving fixes.

That timing makes the next few weeks a planning window, not an upgrade window. This article explains what PostgreSQL 19 changes for operators, which incompatibilities need testing, and how teams on PostgreSQL 14 to 18 can choose a target version and an upgrade route.

Where PostgreSQL 19 stands on the research date

The PostgreSQL 19 RC 1 announcement sets out the schedule. RC 2 is planned for 12 November 2026, and GA for 19 November 2026. The project’s general guidance is that release candidates are for testing against typical workloads, not for production. The PostgreSQL 19 release notes were still marked with an undetermined release date when we read them.

Supported versions matter as much as the new one. The PostgreSQL versioning policy states that each major version is supported for five years after its first release. After that, a final minor release ships and the version is end-of-life. On the research date the policy listed:

Major version	Current minor	Final release (end of fixes)
18	18.6	14 November 2030
17	17.11	Per the versioning page
16	16.15	Per the versioning page
15	15.19	Per the versioning page
14	14.24	12 November 2026

The same page recommends always running the current minor release of your major version. Minor upgrades replace binaries and keep the data directory, so they carry far less risk than a major upgrade. Bring every cluster to its current minor release before planning anything larger.

What PostgreSQL 19 changes for operations

The release notes list many changes. The ones below most directly affect how a platform team runs PostgreSQL.

• REPACK. A new command rewrites a table to reclaim space, optionally ordering it by an index. The release notes describe it as replacing VACUUM FULL and CLUSTER, which remain for compatibility. REPACK (CONCURRENTLY) avoids blocking reads and writes for most of the operation.
• Parallel autovacuum and prioritisation. Autovacuum can use parallel workers for indexes, controlled by autovacuum_max_parallel_workers and a per-table storage parameter. A new scoring system, with configurable weights, decides the order in which tables are processed. A new pg_stat_autovacuum_scores view exposes it.
• Logical replication without a restart. When wal_level is replica, logical replication can now be enabled automatically when needed. A new effective_wal_level setting reports the level in force.
• Sequence replication. Subscribers can now synchronise sequence values with the publisher, and publications can include ALL SEQUENCES. Tables can be excluded from ALL TABLES publications with EXCEPT.
• Read-your-writes on standbys. A new WAIT command lets a session on a standby wait until a given WAL position has been replayed.
• Planner control. The pg_plan_advice and pg_stash_advice modules let teams influence planner decisions and apply advice automatically per query.
• I/O and monitoring. With io_method = worker, the number of I/O workers now scales between configured bounds. New views include pg_stat_lock and pg_stat_recovery, and EXPLAIN gains an IO option.

None of these features removes the need for good operating practice. They change which tools a runbook uses. For example, a runbook that schedules VACUUM FULL during a maintenance window may move to REPACK (CONCURRENTLY), but only after its own constraints are understood.

Incompatibilities to test before you upgrade

The release notes’ migration section lists changes that can alter behaviour after an upgrade. The upgrade documentation asks readers to pay particular attention to that section, and to read the notes of every intervening major version too. These are the items we would test first:

Change	Why it matters
JIT is disabled by default	Sites running many large analytical queries must enable JIT explicitly if they rely on it. Compare plans and run times before and after.
max_locks_per_transaction default rises from 64 to 128	Lock allocation changed, so existing explicit settings must be doubled to keep the same capacity.
standard_conforming_strings is always on	Dumps taken by older pg_dump with the setting off will not load properly. Use the PostgreSQL 19 dump tools.
RADIUS authentication removed	Any pg_hba.conf entry using RADIUS needs another method before upgrading.
Warning after MD5 password authentication	MD5 was deprecated in PostgreSQL 18. Plan the move to SCRAM, or expect warnings in client logs.
btree_gist inet/cidr indexes	pg_upgrade refuses clusters that contain them, because those opclasses can miss rows.
Line breaks banned in database, role and tablespace names	pg_upgrade refuses clusters that use such names.
json_array() over no rows returns []	Code that tested for NULL needs review.
READ ONLY passed to postgres_fdw	Read-only transactions can no longer modify rows through foreign tables.
Renamed monitoring objects	sync_error_count becomes sync_table_error_count, and the BUFFERPIN wait event type becomes BUFFER. Dashboards and alerts need updates.
MULE_INTERNAL encoding removed	Affected databases must be dumped and restored with another encoding.

Two default changes are not listed as incompatibilities but still affect operations. Default TOAST compression moves from pglz to lz4, and log_lock_waits is now on by default. Check log volume and storage behaviour in a test environment.

REPACK CONCURRENTLY: useful, with real constraints

Online table rewrites have long needed external extensions. The REPACK documentation now offers a built-in route, and it is worth reading closely before use.

• Locking. Plain REPACK holds an ACCESS EXCLUSIVE lock throughout. With CONCURRENTLY, most work runs under a weaker lock, and the exclusive lock is taken only for the final swap.
• MVCC. The documentation warns that the concurrent form is not MVCC-safe. Transactions using a snapshot taken before the repack started may see the table as empty after it commits.
• Replication slots. Concurrent changes are captured with logical decoding, so a slot must be available under max_repack_replication_slots.
• Disk space. The command builds a full copy of the table and its indexes. Sorting for USING INDEX can need more space again.
• Eligibility. The concurrent form needs a primary key or an index-based replica identity. It is not allowed for partitioned tables, unlogged tables or materialized views, among others.
• Long transaction. The command counts as one long transaction, which holds back vacuum cleanup on other tables. It is also not a remedy for transaction ID wraparound; VACUUM remains the tool for that.

The RC 1 announcement lists several fixes to REPACK (CONCURRENTLY) during the beta period. That is normal for a new feature, and a reason to trial it on copies of real tables before adopting it in production runbooks.

Choosing an upgrade route

The upgrade documentation describes three methods. Each suits a different downtime budget and risk profile.

Method	How it works	Trade-offs
pg_dumpall and restore	Logical dump from the old version, restore into a new cluster	Simple and well understood. Downtime grows with database size. Use the newer version’s dump tools.
pg_upgrade	Migrates the data directory in place, optionally with --link	Usually much shorter downtime. Needs both binaries installed, and fails on the blocked items above.
Logical replication	A new-version server replicates from the old primary, then you switch over	Shortest switch-over. More moving parts: replica identity, DDL freeze, sequences and extensions all need care.

PostgreSQL 19’s sequence replication and automatic enablement of logical replication may simplify later logical upgrades. Confirm how they behave when the publisher runs an older major version before relying on them for a move from 14 to 18. Whatever the method, keep the old installation until the new one is proven, and rehearse rollback.

If you are still on PostgreSQL 14

PostgreSQL 14 reaches its final release on 12 November 2026, one week before the planned PostgreSQL 19 GA. After that date, community fixes stop. Teams have two reasonable choices:

• Move to PostgreSQL 18 now. It is a supported, released version with minor releases already shipped. This is usually the lower-risk route for systems that must leave 14 soon.
• Wait for PostgreSQL 19 GA and its early minor releases. This avoids a second major upgrade sooner, but leaves 14 running without community fixes for a period. That risk needs an explicit owner and compensating controls.

Either way, a skipped version is fine: the upgrade documentation confirms you can upgrade across several major versions at once, provided you read each intervening release’s notes. Independent support can help a team manage risk during the gap, but it does not replace upstream fixes. Our open-source support model explains how we handle that boundary.

A test plan for the release-candidate window

1. Bring every production cluster to its current minor release.
2. Inventory extensions, authentication methods, encodings and btree_gist indexes on inet or cidr columns.
3. Restore a recent backup into a PostgreSQL 19 RC test cluster using the method you plan to use in production.
4. Run pg_upgrade --check against a copy of each cluster and record every blocker.
5. Replay representative workload, comparing plans with JIT on and off where analytics matter.
6. Review explicit settings for max_locks_per_transaction and other changed defaults.
7. Update dashboards and alerts for renamed views, columns and wait events.
8. Trial REPACK (CONCURRENTLY) and parallel autovacuum on copies of large tables.
9. Report any defect you find to the project during the RC period.
10. Schedule the production upgrade after GA and at least one minor release, unless an end-of-life date forces an earlier move to 18.

How Bassirah can help

We help teams inventory their PostgreSQL estate, choose a target version and upgrade route, and rehearse upgrades and rollbacks on realistic copies of production. Our work is independent engineering under our PostgreSQL support; upstream fixes follow the community’s timeline. For larger moves, see migration and modernization.