PostgreSQL 19 - what changes and what breaks

PostgreSQL 19 is the next major release, and as of the last review it is still in beta: Beta 4 shipped on 24 September 2026 and no release candidate had followed it. The release notes carry a placeholder date (“2026-??-??”), so treat everything here as the documented beta behaviour, not shipped behaviour. Each feature area below links to a page that goes deep; the upgrade breakers at the end are the part to read before touching a cluster.

REPACK

19 adds a core REPACK command that rewrites a table to reclaim space or restore order - the functionality of VACUUM FULL and CLUSTER in one. REPACK CONCURRENTLY does it without blocking reads and writes, replacing the trigger-and-log-table trick of the pg_repack extension with logical decoding over a replication slot. It needs wal_level = logical for the concurrent mode. REPACK covers both modes, the lock behaviour, and when the extension is still the answer on older releases.

Replication and the WAIT command

WAIT FOR LSN lets a session pause until a standby has written, flushed or replayed WAL up to a point - the primitive that makes read-your-writes work on asynchronous replicas, with a timeout and NO_THROW for the fallback path. Logical replication gains sequence support (FOR ALL SEQUENCES, REFRESH SEQUENCES, pg_get_sequence_data()), an EXCEPT table list on FOR ALL TABLES publications, retain_dead_tuples with max_retention_duration for conflict detection, CREATE SUBSCRIPTION ... SERVER using postgres_fdw connection parameters, per-subscription wal_receiver_timeout, and wal_sender_shutdown_timeout. wal_level = replica can now enable logical capability automatically, reported through effective_wal_level. Replication and WAIT walks a worked read-your-writes timeline and all of it.

Autovacuum

Two changes that matter independently. Index vacuuming can run in parallel workers now, governed by autovacuum_max_parallel_workers and a per-table autovacuum_parallel_workers storage parameter. And the order in which autovacuum picks tables changed from catalogue order to a five-component score - freeze age, multixact age, update/delete and insert dead tuples, and analyse staleness - each with a weight GUC. pg_stat_autovacuum_scores shows the reasoning, and the wraparound warning fires at 100 million remaining IDs instead of 40 million. Autovacuum has a worked tuning example.

Plan advice

pg_plan_advice is a core extension that describes planner decisions as a text mini-language - scan methods, join orders, join methods, partitionwise and parallel choices - which you edit and feed back to constrain the plan, with EXPLAIN feedback reporting whether each piece of advice matched. pg_stash_advice stores those strings keyed by query ID and applies them automatically. It is the in-core answer to plan instability, and it is not pg_hint_plan: advice can only select between plans the planner would have considered. Plan advice shows a before/after plan and the failure modes.

Asynchronous I/O

The I/O subsystem that arrived in 18 gets an elastic worker pool: io_method = worker now scales between io_min_workers (2) and io_max_workers (8), retiring idle workers after io_worker_idle_timeout (1 minute) and launching no faster than io_worker_launch_interval (100 ms), replacing the fixed io_workers count. Read-ahead scheduling improves for large requests, and EXPLAIN (ANALYZE, IO) reports prefetch queue depth, request counts, waits and average concurrency per scan node, with auto_explain.log_io for logged plans. Asynchronous I/O has the details.

Monitoring

pg_stat_lock accumulates lock-type contention (waits over deadlock_timeout), pg_stat_recovery reports standby replay and promotion state, pg_stat_wal gains wal_fpi_bytes, pg_stat_replication_slots gains mem_exceeded_count and slot-sync skip columns, and stats_reset columns spread across the table, index, sequence, function and conflict views. log_min_messages accepts a per-process-type type:level syntax, log_lock_waits is on by default, log_autoanalyze_min_duration splits analyse logging out, and new wait events cover COPY I/O, commit_delay, WAL LSN waits and the WAIT command. Monitoring is a runbook of the queries.

SQL and COPY

INSERT ... ON CONFLICT DO SELECT [FOR UPDATE] returns the conflicting row instead of writing over it - an idempotent get-or-create. Window functions gain IGNORE NULLS/RESPECT NULLS on lead, lag, first_value, last_value and nth_value. COPY adds a JSON output format with FORCE_ARRAY, ON_ERROR SET_NULL for bad input, multi-line HEADER skipping, and direct COPY TO on partitioned tables. Smaller items: GRANTED BY, CHECK constraint ENFORCED toggles, oid8, jsonpath string methods, temporal random(), base64url and base32hex, and several utility functions and casts. SQL and COPY covers them.

Maintenance extensions

Four contrib modules did not change in 19 but became more relevant to it: pg_visibility verifies the visibility-map bits that table scans can now set, pgrowlocks shows per-row locks where the new pg_stat_lock shows only per-type contention, pg_surgery is the last resort when corruption makes a table unvacuumable - the worst possible position under the new freeze scoring - and pg_prewarm warms caches around restart and benchmarking. Maintenance extensions covers the functions and the cautions.

Performance

The smaller executor and planner changes, which do not each rate a page:

• NOT IN converts to an ANTI JOIN when NULLs cannot occur; more LEFT JOINs convert too, and Memoize applies to anti joins with unique inner sides.
• Foreign-key constraint checks are faster, which shows up on write-heavy workloads against referenced tables.
• Sorting uses radix sort where applicable; hash join handles NULL join keys better; some aggregate work can be pushed below joins; TID range scans can be parallelised.
• COPY FROM text/CSV parsing and hex_encode/hex_decode use SIMD CPU instructions; internal row deformation and UTF-8 case folding are faster; hash index bulk-deletion and GIN vacuuming use streaming reads.
• NOTIFY now wakes only backends listening on the notified channel - previously most backends woke on any notification.
• Table scans can set visibility-map all-visible bits, previously a VACUUM/COPY FREEZE job.
• timing_clock_source controls the timing source; EXPLAIN (ANALYZE, TIMING) and pg_test_timing benefit.

What is not in 19

The SQL/PGQ property-graph syntax (GRAPH_TABLE) does not appear in the release notes and its documentation pages return 404 - it is not shipping in 19 despite occasional write-ups listing it. Also absent from the release: io_uring remains unavailable as an io_method in the documented options.

Upgrade breakers

These are the incompatibilities listed in the release notes’ migration section - the changes that make an upgrade fail or behave differently rather than merely add features. The last column is what to check on your current cluster before you run pg_upgrade.

Several of these are silent behaviour changes rather than hard failures: log_lock_waits on by default adds log lines, lz4 changes CPU characteristics of TOAST writes, and the NOT IN to anti join transformation can change plans. The hard blockers are the ones pg_upgrade refuses on: btree_gist inet/cidr indexes, CR/LF in names, and MULE_INTERNAL databases.

Where to next

Each sub-page goes deeper on one area, including the “what changed” tables against PostgreSQL 18:

• REPACK - the new core command and its CONCURRENTLY mode versus the pg_repack extension
• Replication and WAIT - read-your-writes on standbys, sequence replication, EXCEPT, retain_dead_tuples
• Autovacuum - parallel index vacuuming and the new scoring system
• Asynchronous I/O - worker autoscaling, read-ahead, EXPLAIN (ANALYZE, IO)
• Monitoring - pg_stat_lock, pg_stat_recovery, wait events, logging changes
• Plan advice - pg_plan_advice and pg_stash_advice
• SQL and COPY - the smaller SQL additions and NOT IN to anti join
• Maintenance extensions - pg_visibility, pg_surgery, pg_prewarm, pgrowlocks: unchanged in 19, but the inspection tools for what it changed

What this page is not for

It is a map, not the territory: it does not replace the per-feature pages linked above, and it is not upgrade instructions. For the mechanics of an actual upgrade - pg_upgrade versus dump/restore versus logical replication - the release notes’ migration section and the installation page are the references. Everything here is beta documentation and can still change before GA.

Because 19 is pre-release, expect this area to be revised at each beta and again at GA.