How to Plan PostgreSQL Maintenance Storage

Why ordinary database size is not the maintenance requirement

A PostgreSQL cluster can fit comfortably during normal service and still cross a filesystem boundary during maintenance. VACUUM FULL writes a new table file before releasing the old one. CREATE INDEX and REINDEX produce new index output and can use temporary workspace. Replication slots intentionally preserve WAL for consumers that have not advanced. A physical base backup transfers a source that continues to generate WAL. Each operation has a different peak, trigger, and recovery action.

Do not collapse those questions into “How large is my database?” The steady footprint answers a procurement question. The operation peak answers whether one task can complete without filling a particular filesystem. Record the tablespace, mount, and time of every measurement so free bytes from the wrong device are never counted.

Build a measurement sheet before choosing a command

For a table rewrite, capture the table, TOAST, and index sizes separately. Estimate the rewritten relation from live-tuple or staging evidence, not a universal bloat percentage. For index work, record expected new index output, simultaneous build count, temporary files, and the writes expected during the window. For WAL, measure actual bytes per hour across both typical and busy periods, then record retained bytes and the consumer's recovery deadline. For a base backup, measure the output format's payload and effective end-to-end throughput.

Use decimal GB consistently in the tools or convert every value to another common unit before comparison. PostgreSQL and operating-system surfaces can report raw bytes, MB, MiB, GB, or GiB. Keep the original measurement beside the converted value so another reviewer can reproduce it.

Preserve free-space reserve as an explicit decision

A plan that reaches zero free bytes exactly is not a safe plan. Monitoring lag, filesystem metadata, unrelated logs, temp files, write bursts, snapshots, and estimate error can all consume the last margin. The planners keep reserve editable because no single percentage is an official PostgreSQL threshold for every system. Choose it from observed variance, alert response time, and the consequence of a full disk, then document why.

Use the VACUUM FULL Disk Space Checker or Index Build & Reindex Space Planner before a rewrite. A pass means the byte assumptions fit; it does not evaluate locks, query impact, or whether the operation is the right maintenance choice.

Treat WAL retention as a deadline

Replication slots protect a standby or logical consumer by preventing removal of required WAL. That protection can fill the primary's WAL filesystem when the consumer stalls. Measure the generation rate and calculate how long the chosen disk allocation and any configured slot cap can support the lag. Alert early enough to diagnose and rebuild a consumer without improvising under a full-disk incident.

The WAL Retention & Replication Slot Planner shows the shorter boundary. Never remove or advance a slot just because its files are large; first identify the owner, the required LSN, and whether a fresh copy is necessary.

Model backup bytes that arrive during the backup

PostgreSQL documentation notes that a pg_basebackup estimate can increase when WAL is included. A slow path gives the source more time to generate WAL, which creates more bytes to transfer. The Base Backup Storage & Transfer Planner solves that feedback with measured effective throughput and WAL rate. It also checks one or more target copies against free capacity after reserve.

Capacity is not recovery evidence. Preserve the manifest and command output, verify every tablespace, and restore into an isolated environment. A backup that completed and occupied the expected bytes can still be unusable if its WAL, configuration, encryption key, or restore procedure is missing.

A repeatable maintenance review

1. Name the operation and exact filesystem boundary.
2. Measure current relation, index, free-space, WAL, and stream values.
3. Convert units without discarding the source reading.
4. Select an evidence-based reserve and growth allowance.
5. Run the matching preflight and save the result.
6. Review command locks, tablespaces, version behavior, monitoring, and cancellation cleanup.
7. Preserve a rollback or rebuild path before execution.
8. Compare actual peak and duration with the plan and update the next run.

Technical sources and next steps

Use the current official PostgreSQL documentation for VACUUM, REINDEX, replication slots and WAL retention, and pg_basebackup. These sources define behavior; the planners expose measurements and reserves instead of embedding a server version or managed-provider policy.

Audit the arithmetic in the PostgreSQL Maintenance Storage Formulas. After capacity passes, test the operation on representative data when practical and record observed peak bytes, duration, alerts, cleanup, and recovery evidence.