PostgreSQL 19 release candidate: what to look at before the final release

PostgreSQL 19 is not final yet. According to the draft release notes, release candidate 1 came out on October 15, 2026, and the final date is still a placeholder. That makes this a good moment to read the notes, try it on a copy of your data, and plan, without any pressure to upgrade production.

Below is a tour of the items that stood out to me, grouped by who is likely to care. Release notes can change before the final version, so treat this as a map and read the real thing for details.

Maintenance gets easier

REPACK

The new REPACK command takes over the territory of VACUUM FULL and CLUSTER, which stay for compatibility. It reclaims disk space and reorders table contents. The part many operators will notice is REPACK (CONCURRENTLY), which rebuilds a table without taking an access-exclusive lock, so reads and writes can continue. A new setting, max_repack_replication_slots, supports it.

If you have ever put off compacting a bloated table because the lock would stop your application, this is the feature to test first. As always with online rebuilds, try it on a copy and watch disk space and replication lag while it runs.

Parallel autovacuum and scoring

Autovacuum can now use parallel workers when processing a table's indexes. The ceiling is set with autovacuum_max_parallel_workers, with a per-table storage parameter, autovacuum_parallel_workers, for finer control.

Autovacuum also gains a scoring system that decides which tables to process first, tuned with the autovacuum_*_score_weight settings. A new view, pg_stat_autovacuum_scores, shows the scores, so you can see why one table was chosen over another. That is a helpful addition: tuning anything is easier when you can inspect its decisions.

I/O and query performance

With io_method = worker, the server now manages the number of background I/O workers itself. You set bounds through io_min_workers and io_max_workers, plus io_worker_idle_timeout and io_worker_launch_interval. Read-ahead scheduling for large requests also improves.

On the query side, the notes list a collection of optimizer work: more conversions of LEFT JOIN to anti joins, Memoize for anti joins, some aggregation done before joins, a radix sort, and parallel TID range scans. Foreign key checks are described as faster too, though the notes do not give numbers. I would not promise yourself a specific speed-up. Measure your own workload before and after.

Two defaults to note: lz4 is now the default TOAST compression, and JIT is disabled by default. If you run large analytical queries that benefited from JIT, you will need to turn it back on yourself.

Logical replication grows up

This release has several practical additions:

• Sequence values can be synchronized to subscribers using CREATE PUBLICATION ... ALL SEQUENCES and ALTER SUBSCRIPTION ... REFRESH SEQUENCES. Anyone who has done a logical-replication cutover and then fixed sequences by hand will appreciate this.
• EXCEPT lets you leave tables out when publishing ALL TABLES.
• The retain_dead_tuples subscription setting keeps the data needed for conflict detection, and max_retention_duration limits how long it is kept.
• When wal_level is replica, logical replication can be enabled without a restart, and a new effective_wal_level setting reports what is actually in force.
• wal_receiver_timeout can be set per subscription and per user.

Standbys: read your own writes

A new WAIT command lets a session on a standby wait until a given log position has been written, flushed or replayed. In plain words: you write on the primary, note the position, and then ask the replica to catch up to it before reading. That supports read-your-writes behaviour without sending every read to the primary. A sketch of the idea:

-- on the primary, after writing
SELECT pg_current_wal_lsn();

-- on the standby, before reading
-- wait until that position is replayed (see the WAIT command in the docs for the exact syntax)

Check the final documentation for the precise syntax; I have deliberately not guessed it here.

Monitoring

New views include pg_stat_lock, pg_stat_recovery and the autovacuum scores view mentioned above. More visibility into locks and recovery is rarely unwelcome.

Security and housekeeping

RADIUS authentication support is removed. Postgres now warns after a successful login using MD5 password authentication, and warns about passwords nearing expiry. The pg_read_all_data and pg_write_all_data roles can now also read and write large objects. The notes list no changes to row-level security in this release; if you want a refresher on that feature, see our guide to row-level security.

Migration checklist

Upgrading from an earlier release needs a dump and restore, pg_upgrade, or logical replication. Beyond that, the notes call out a few items worth checking:

1. JIT is off by default. Decide whether you want it on for analytic workloads.
2. standard_conforming_strings is always on at the server.
3. max_locks_per_transaction now defaults to 128 instead of 64.
4. If you rely on RADIUS authentication, plan an alternative.
5. Review any scripts that call VACUUM FULL or CLUSTER; consider whether REPACK suits them better.

How I would try it

Restore a recent backup into a test instance of the release candidate. Run your slowest ten queries and compare plans. Run your usual load test. Try REPACK (CONCURRENTLY) on a table you know is bloated. Look at pg_stat_autovacuum_scores for a day. Write down anything surprising, and wait for the final release and its first minor update before you move anything important.

Releases like this one are a nice reminder that databases improve quietly in the places that matter to operators: less locking, better visibility, fewer manual steps.

Sources

• PostgreSQL 19 release notes (draft)