Postgres 19's REPACK rewrites a bloated table without locking out your writers

8.5 relevance

Postgres 19 REPACK feature with detailed concurrency benchmarks, highly actionable and directly relevant to data engineering.

General dev.to

Answer the board on AI readiness

Arrive with evidence, not opinion. See how your foundation benchmarks against your peers, get a clear read, and leave with a ranked place to start.

Why It Matters

For platform engineers running user-facing Postgres on GCP or AWS, this eliminates the painful choice between table bloat and application downtime, making online DDL-style maintenance practical for production workloads.

Key Takeaways

Plan to adopt REPACK (CONCURRENTLY) for zero-downtime table rewrites in Postgres 19, but benchmark your write throughput to ensure the logical decoding catch-up phase converges before production use.

Postgres 19's REPACK rewrites a bloated table without locking out your writers

Summary

PostgreSQL 19 beta 3 introduces REPACK (CONCURRENTLY), which rewrites bloated tables to reclaim space and reorder by index without blocking reads or writes, unlike VACUUM FULL's ACCESS EXCLUSIVE lock. In benchmarks, REPACK (CONCURRENTLY) served 3,988 writes during a 4.32s rewrite versus VACUUM FULL's 33 writes in 0.97s, and allowed 384 reads versus 1 read during maintenance. The tradeoff is longer total duration for zero downtime, with a brief lock only during the final file swap, and progress is observable via pg_stat_progress_repack.

Author

Remdore