Postgres Summit US2026

Bloat is just a fact of Postgres life, and pg_repack is a known standard tool to have in such situations. Usually, it is treated as a highly reactive, manual procedure reserved for emergencies. But what if we stopped treating bloat as an emergency and instead built repacking into our continuous operational lifecycle? Understanding the underlying mechanical trade-offs can unlock a proactive repacking approach.

In high-throughput environments, proactive repacking can lead to reduction in read latencies, increase in write throughput as well as reduced storage footprint. All this comes at the cost of IO, CPU spikes and temporary storage footprint. With native repacking coming in Postgres 19, balancing those tradeoffs allows us to build our own best practices playbook.