Postgres 19 Beta: Built-in REPACK, Smarter Autovacuum, and SQL Graph Queries

The Postgres 19 beta spreads its improvements across operational quality-of-life rather than a single marquee feature. The headline for production operators is REPACK, now built into core with a CONCURRENTLY option — letting teams reclaim table bloat and reorganize data without the heavy locks of VACUUM FULL or CLUSTER, and folding in functionality the pg_repack extension long provided. Partitioning also matures: tables can now be split and merged in place, so a partitioning scheme chosen under uncertainty can evolve as retention windows, data volume, or workload shape change.

Logical replication gets several gaps filled, most notably synchronization of sequence values so subscribers’ next generated IDs stay aligned with publishers after cutover — a frequent post-migration headache. Publications gain ALL SEQUENCES support and an EXCEPT clause to publish everything-but-a-few tables, and wal_level=replica can now auto-enable logical replication when needed, with a new effective_wal_level reporting what’s actually in effect. Autovacuum becomes both more capable and more observable: parallel vacuum workers (tunable globally and per table), a scoring system to prioritize which tables get vacuumed first, the new pg_stat_autovacuum_scores view, and richer detail in progress views and verbose logs.

The most novel addition is SQL/PGQ, bringing property graph queries to Postgres for workloads like fraud detection, recommendations, and permission graphs. In keeping with how Postgres absorbed JSONB, it layers graph querying onto existing relational data rather than forcing a separate architecture. As always with a beta, specifics may shift before GA, but the release reads as a broad, practical step forward for teams running Postgres in production.