PostgreSQL 19 RC 1: What Changes and How to Prepare Before the November GA

What was announced

On 15 October 2026 the PostgreSQL Global Development Group announced the first release candidate of PostgreSQL 19. The announcement says the next scheduled update release for supported versions, on 12 November 2026, will carry a large number of fixes, and the release team decided to include them in 19 before general availability. A second release candidate will therefore ship on 12 November, and general availability is planned for 19 November 2026, unless an issue forces a delay. Fixes since Beta 4 include several for REPACK (CONCURRENTLY), pg_plan_advice, parallel autovacuum and the automatic enablement of logical replication.

A release candidate is the right moment to test an upgrade, because the feature set is fixed and the release notes are close to final. The notes used here are the version 19 release notes as published with RC 1, marked "as of 2026-10-09". Anything not in those notes, including features discussed during development and later removed, is not in PostgreSQL 19.

Incompatibilities that can break an upgrade

Run pg_upgrade --check with the RC binaries against a copy of production. It is the authoritative test for the conditions pg_upgrade refuses, and it is quicker than discovering them during a maintenance window.

Behaviour changes that do not fail loudly

• JIT is disabled by default. The notes say the cost model that switched JIT on was unreliable. Analytical workloads that benefited from JIT will get slower unless you set jit = on. Find them first with pg_stat_statements, which records JIT activity per query.
• max_locks_per_transaction default went from 64 to 128, and lock allocation changed. The notes say existing settings must be doubled to keep the same capacity. A cluster tuned to 256 for many partitions should move to 512.
• Default TOAST compression is lz4 instead of pglz, and wal_compression = on now picks the best available method. Existing data is unchanged; new values compress differently.
• log_lock_waits is on by default. Expect more log lines on contended systems; check log volume alerts.
• MD5 password logins produce a warning, controllable with md5_password_warnings, and password_expiration_warning_threshold warns seven days before expiry by default.
• json_array() with no rows returns an empty array instead of NULL; code that checks for NULL needs a change.
• postgres_fdw sessions inherit READ ONLY and DEFERRABLE, so read-only transactions can no longer modify remote rows.
• Monitoring names changed: wait event type BUFFERPIN is now BUFFER, and sync_error_count in pg_stat_subscription_stats is now sync_table_error_count. Dashboards and alerts that match on the old names go silent.

Pre-upgrade checks you can run today

Illustrative SQL; query 5 needs pg_stat_statements 1.10 or later (PostgreSQL 15+). pg_upgrade --check remains the authoritative test.

-- 1. Roles still using MD5 passwords (superuser required)
SELECT rolname FROM pg_authid WHERE rolpassword LIKE 'md5%';

-- 2. Names that pg_upgrade 19 will refuse
SELECT 'database' AS kind, datname AS name FROM pg_database WHERE datname ~ '[\r\n]'
UNION ALL SELECT 'role', rolname FROM pg_roles WHERE rolname ~ '[\r\n]'
UNION ALL SELECT 'tablespace', spcname FROM pg_tablespace WHERE spcname ~ '[\r\n]';

-- 3. Databases in the removed encoding
SELECT datname FROM pg_database WHERE pg_encoding_to_char(encoding) = 'MULE_INTERNAL';

-- 4. Indexes that use btree_gist network opclasses (run in each database)
SELECT i.indexrelid::regclass AS index_name, oc.opcname
FROM pg_index i
JOIN pg_opclass oc ON oc.oid = ANY (i.indclass::oid[])
WHERE oc.opcname IN ('gist_inet_ops', 'gist_cidr_ops');

-- 5. Queries that currently use JIT (needs pg_stat_statements)
SELECT queryid, calls, jit_functions, jit_generation_time
FROM pg_stat_statements WHERE jit_functions > 0
ORDER BY jit_generation_time DESC LIMIT 20;

-- 6. Current lock table sizing
SHOW max_locks_per_transaction;

Query 4 names the btree_gist operator classes as the extension defines them; confirm against \dAc output in your cluster if you use a fork or an old extension version.

Features worth planning for

Two smaller changes help operations immediately: transaction ID and multixact wraparound warnings now start at 100 million remaining instead of 40 million, and pg_stat_progress_vacuum reports who started a vacuum and how aggressive it is. For the mechanics behind those warnings, see PostgreSQL MVCC and VACUUM.

A test plan between RC 1 and GA

1. Restore a recent production backup into a staging cluster and run pg_upgrade with --check, then a real upgrade, using RC 1 binaries.
2. Replay a captured workload or run your performance suite with jit at the new default, then with jit = on for the analytical queries found by check 5. Compare plans and timings.
3. Double any customized max_locks_per_transaction and run the partition-heavy jobs that needed it.
4. Point dashboards and alerts at the staging cluster and fix every query that matches renamed columns or wait events.
5. Test logical replication and REPACK (CONCURRENTLY) on a large table under write load, watching replication slot usage and WAL volume.
6. Repeat the upgrade with RC 2 on 12 November, and keep the production upgrade for after GA and your own soak period.

What is still uncertain

Release candidates can change: the project says RC 1 is mostly identical to the final release but more fixes may be applied, and the GA date holds only if no blocking issue appears. Performance figures for the new features will depend on your hardware and workload; none are claimed here. Extensions you rely on need version 19 builds, and each extension project ships on its own schedule. Re-read the final release notes on GA day and diff them against the RC notes before the production change.

Practice and related reading

Further reading:

• PostgreSQL MVCC and VACUUM
• Vacuum and bloat architecture
• PgBouncer 1.26.1 security release

Sources and scope

Checked against these sources on 17 October 2026. Event: PostgreSQL 19 RC 1 announcement, 15 October 2026; recheck it before acting. Examples and figures are illustrative, not measurements.

• PostgreSQL news: PostgreSQL 19 RC 1 Released (2026-10-15)
• PostgreSQL 19 release notes
• PostgreSQL 19 documentation: pg_upgrade