PostgreSQL 19 Beta 1: WAIT FOR LSN and the JIT Gotcha

PostgreSQL 19 Beta 1 landed on June 4, 2026. GA is still a few months out — September or October — but three features are worth understanding now. One solves a replica-consistency problem that developers have been hacking around for years. One flips a default that could quietly regress your analytical queries after an upgrade. One cleans up a maintenance headache for teams running heavily-indexed tables. Here is what changed and what you need to check before you upgrade.

WAIT FOR LSN: The Stale Read Fix You Have Been Waiting For

If you have ever written data to a PostgreSQL primary and immediately read from a replica only to miss your own write, you know the pain. The standard workarounds are inelegant: sleep and retry, force all post-write reads to primary, or maintain application-level bookkeeping. None of these scale cleanly.

PostgreSQL 19 adds WAIT FOR LSN, a command that blocks a replica session until a specific Log Sequence Number has been replayed before executing a query. The flow looks like this:

-- After writing on the primary, capture the LSN:
SELECT pg_current_wal_lsn();  -- returns e.g. '0/1234567'

-- On the replica, wait for that position before reading:
SELECT WAIT FOR LSN '0/1234567' ON STANDBY REPLAY TIMEOUT '5s';
SELECT * FROM orders WHERE id = 42;

Three wait modes are available: standby_write (WAL on disk, fastest), standby_flush (WAL durable), and standby_replay (the default — WAL replayed and visible to readers). For most CQRS and event-driven architectures, standby_replay is what you want. MongoDB has offered Causal Consistency for years; PostgreSQL now has a native equivalent. MySQL still does not.

JIT Is Off by Default — Check Your Analytical Queries

JIT compilation has been on by default since PostgreSQL 12. In PostgreSQL 19, it defaults to off. This is the right call — AWS, Google, and Azure have all been disabling JIT in their managed PostgreSQL offerings for years — but if you run analytical workloads on self-managed PostgreSQL, you may see query regressions after upgrading without knowing why.

JIT genuinely helps long-running queries with heavy aggregations and sequential scans. It hurts OLTP workloads because the compilation overhead exceeds the benefit for short queries. The problem is that a lot of deployments have been silently benefiting from JIT on reporting queries without explicitly enabling it.

Before you upgrade, check whether JIT is doing anything useful for you:

EXPLAIN (ANALYZE, BUFFERS) SELECT ... -- your slowest analytical query

Look for a JIT: section in the output. If it is there and showing meaningful time savings, add jit = on to your postgresql.conf after upgrading to 19. If you do not see a JIT section, this change does not affect you.

Parallel Autovacuum: Real Wins for Heavily-Indexed Tables

Autovacuum can now clean multiple indexes in parallel within a single vacuum run. The feature is controlled by two new parameters: autovacuum_max_parallel_workers sets the cluster-wide cap, and the per-table storage parameter autovacuum_parallel_workers lets you tune individual tables. Workers come from the existing max_parallel_workers budget.

The important caveat: the gain is only on the index cleanup phase, and only for tables with many or expensive indexes. A table with a GIN index on a jsonb column and several B-tree indexes is the ideal case — the GIN cleanup alone often dominates vacuum time, and handing it off to a parallel worker while the leader handles the B-trees is an actual win. A table with one or two simple B-tree indexes will see no benefit.

The default is zero parallel workers, which is the correct default for most clusters. If you do enable this, check your memory arithmetic first: autovacuum_max_workers × autovacuum_max_parallel_workers × maintenance_work_mem. Teams that have cranked maintenance_work_mem to 4 GB should run the numbers before upgrading.

Two More Worth Knowing

Async I/O auto-scales. Building on PG18’s async I/O subsystem, io_method=worker now auto-tunes its worker pool between io_min_workers and io_max_workers based on actual I/O demand. Less manual tuning required. EXPLAIN (ANALYZE, IO) is also new — it reports reads issued, reads completed, and bytes transferred per plan node, which is useful when you suspect I/O is the bottleneck.

SQL/PGQ arrives (experimental). PostgreSQL 19 includes the first implementation of SQL/PGQ (ISO SQL:2023), which lets you run property graph queries over existing relational tables using pattern-matching syntax — no schema migration, no extensions, no graph database required. Treat this as preview quality for now; the syntax may shift before GA.

Breaking Change: RADIUS Authentication Is Gone

PostgreSQL 19 removes the radius authentication method from pg_hba.conf entirely. The server will refuse to start if radius lines are present. RADIUS over UDP is unfixably insecure, the user base was small, and the right answer is PAM. Check your pg_hba.conf before upgrading.

How to Test Now

Beta 1 is available today. The PostgreSQL project explicitly asks developers to run their test suites against it. The quickest path:

docker pull postgres:19-beta1
docker run --name pg19-test -e POSTGRES_PASSWORD=test -p 5432:5432 -d postgres:19-beta1

Or use pgenv build 19beta1 if you manage multiple PostgreSQL versions locally. The official PostgreSQL 19 Beta 1 announcement has links to source tarballs and binary packages.

GA is roughly three months out. Testing now means fewer surprises in production — and if you find a bug, the project wants to know through their bug reporting page. The more testing during beta, the cleaner the GA will be.