PostgreSQL 19 Beta 1: Online REPACK, Parallel Autovacuum, and What to Test Before GA

PostgreSQL 19 Beta 1 is out, and the feature worth testing first isn’t a new data type or a query planner trick. It’s REPACK, a command that finally lets you rewrite a bloated table without locking it for the duration. If you’ve ever scheduled a maintenance window for VACUUM FULL or installed the pg_repack extension because you couldn’t afford one, this release is aimed directly at you.

REPACK: the feature most teams have been waiting for

VACUUM FULL and CLUSTER have always done useful things: reclaim space from a bloated table, or physically reorder rows to match an index for faster range scans. The problem was never what they did, it was the lock. Both take an ACCESS EXCLUSIVE lock for the entire rewrite, which on a table with millions of rows can mean minutes or hours of downtime for that table.

PostgreSQL 19 merges both operations into a single REPACK command, and adds a CONCURRENTLY option that changes the locking story entirely:

-- Reclaim space, equivalent to the old VACUUM FULL, without blocking reads/writes
REPACK CONCURRENTLY orders;

-- Rewrite in index order, equivalent to the old CLUSTER
REPACK CONCURRENTLY orders USING orders_created_at_idx;

Under CONCURRENTLY, Postgres builds the new table version in the background using a replication slot to capture concurrent changes, then swaps the old and new files in a single fast step. The ACCESS EXCLUSIVE lock only applies to that final swap, not the whole rewrite. Reads and writes continue against the table for the bulk of the operation.

This has been the entire reason the pg_repack extension exists: it does roughly this today, but as a third-party tool you have to install, trust, and re-verify against every major version upgrade. If REPACK CONCURRENTLY performs as advertised through the beta cycle, most teams running pg_repack today have a clear path to dropping the extension once they’re on 19.

Parallel autovacuum and a smarter scheduler

Autovacuum has historically worked through tables largely in the order it discovers them need attention, one worker per table. PostgreSQL 19 lets a single table use multiple parallel workers, controlled by the new autovacuum_max_parallel_workers setting, which shortens vacuum time on your largest, most bloat-prone tables.

The bigger operational change is a new scoring system for deciding which tables to vacuum first when autovacuum is behind. Instead of a fixed traversal order, the scheduler prioritizes based on how urgently a table needs attention. If you’ve hand-tuned per-table autovacuum thresholds to work around the old ordering behavior, re-test those settings against 19 rather than assuming they translate directly; the thing you were compensating for has changed shape.

Async I/O keeps maturing

PostgreSQL 18 introduced the async I/O (AIO) subsystem. 19 builds on it with automatic worker scaling: io_min_workers and io_max_workers let the number of I/O workers grow and shrink with load instead of running a fixed pool, with io_worker_idle_timeout and io_worker_launch_interval controlling how aggressively that scaling happens.

EXPLAIN ANALYZE also gains an IO option that surfaces AIO statistics directly in query plans, which matters if you’re trying to understand whether a slow query is actually I/O-bound under the new subsystem or bottlenecked somewhere else. Up to now that’s been a guessing game involving pg_stat_io and timing correlation; having it in the plan output directly is a real debugging improvement.

What to test now, and what to wait for

Area	What changed	Test priority
REPACK	New command, replaces VACUUM FULL / CLUSTER / pg_repack use cases	High: test against a staging copy of your largest tables
Autovacuum	Parallel workers, new prioritization scoring	High if you hand-tune autovacuum settings
Async I/O	Auto-scaling workers, EXPLAIN ANALYZE IO stats	Medium: useful visibility, low risk to adopt
Virtual generated columns	CHECK constraints now allowed on virtual columns	Low unless you use generated columns heavily

This is a beta, not a release candidate. The PostgreSQL project’s own release process runs one or more additional betas, then a release candidate, before general availability, historically landing around September or October based on the project’s yearly cadence. Test your application, your extensions, and your migration tooling against it now on a non-production copy, and file bugs; that’s what the beta period exists for. If you’re mid-planning a schema change or considering a zero-downtime migration for later this year, it’s worth knowing REPACK CONCURRENTLY will likely be available by the time you execute it, since it changes what “zero-downtime table rewrite” actually requires in your toolkit.

Spin up the beta against a staging snapshot this week if bloat management or vacuum tuning has been a recurring pain point. Report what breaks. That’s how this feature ships solid by GA instead of shipping with the sharp edges still attached.