VACUUM FULL Disk Space Checker
Compare a conservative rewritten table and index working set with current free disk after reserve.
Check rewrite spaceDatabase operation disk preflight
Check rewrite working space, index-build peaks, retained WAL growth, and base-backup targets with measured sizes and rates before an operation reaches a storage boundary.
Compare a conservative rewritten table and index working set with current free disk after reserve.
Check rewrite spaceBudget new index output, simultaneous builds, temporary work, and concurrent write growth.
Plan index spaceTurn a measured WAL rate and consumer lag into retained bytes, boundary time, and a safe lag window.
Plan WAL retentionEstimate backup duration and target footprint while WAL continues to be generated during the stream.
Plan a base backupA database can have enough long-term capacity and still fail a maintenance operation. A table rewrite needs a new relation before the old one disappears. An index build creates new output and may use temporary sort space. A delayed replication consumer can retain WAL until the primary disk reaches a threshold. A physical base backup grows while the source keeps writing. These are operation-specific peaks, not ordinary annual database growth.
Read How to Plan PostgreSQL Maintenance Storage and audit the equations in the PostgreSQL Maintenance Storage Formulas.
Recommended workflow
Start with the immediate failure mode. Use the rewrite checker when VACUUM FULL is being considered to return table space to the operating system. Use the index planner before CREATE INDEX or REINDEX work. Use the WAL planner for a delayed standby, logical consumer, archive outage, or replication slot. Use the base-backup planner when a new physical copy must finish within a target capacity and transfer window.
Record current free bytes and relation sizes from the exact tablespaces involved. Measure WAL generation across a representative busy period and backup throughput from a real path. Run the relevant preflight with explicit reserve, schedule only after the modeled boundary passes, and monitor actual free space throughout execution. Re-run after a schema change, workload increase, new replica, backup format change, or storage move.
Bring table and TOAST size, index size, expected rewritten output, temporary build allowance, filesystem free space, measured WAL bytes per hour, current retained WAL, planned consumer lag, configured slot cap if any, effective base-backup throughput, target free capacity, and the source of every measurement. Use the current PostgreSQL documentation for command behavior and version-specific limits.
A pass is permission to continue verification, not permission to run an intrusive command unattended. Confirm locks, tablespaces, archive and slot state, restore evidence, alert thresholds, and rollback steps. If the storage boundary is tight, add capacity or reduce scope before execution. Use the VM & Container SSD Endurance Planner only after measured maintenance writes need a separate endurance review.