VACUUM is PostgreSQL maintenance for the row versions that MVCC leaves behind after data changes. Deleted or obsolete tuples are not immediately removed from table files; VACUUM clears them so PostgreSQL can reuse their space. It also cleans corresponding table indexes and can freeze old rows to protect against transaction-ID wraparound. section 6.7
A common mistake is treating vacuuming as expendable background work. Autovacuum can consume resources at inconvenient times, and disabling it may appear to improve performance briefly. The cost arrives later as unreclaimed dead tuples, table and index bloat, stale planning information, and maintenance risks accumulate. Autovacuum checks whether tables need VACUUM or ANALYZE and performs the needed work, reducing the need for manual intervention. section 6.7
VACUUM contributes to several operational concerns:
- Reuses cleared space inside a table’s existing data files rather than necessarily shrinking those files. section 6.7 section 7.1
- Cleans indexes as well as heap tables, limiting the accumulation of obsolete index entries. section 6.7
- Supports query planning when run as VACUUM ANALYZE, which collects table-content statistics after vacuuming. section 6.7
- Helps prevent XID wraparound by freezing old table rows; PostgreSQL still watches for XID exhaustion even if autovacuum is disabled. section 6.7
Deleting data does not immediately solve a full disk
When a database runs out of disk, deleting old rows is not an instant escape hatch. DELETE and TRUNCATE require WAL writes, so available disk is needed to make the change. After a DELETE, dead rows still need VACUUM before their space becomes reusable. Ordinary VACUUM marks that space free within the table files; it does not return it to the operating system. section 7.1
ERROR: could not extend file "base/12609/16048": No space left on device HINT: Check free disk space.
A file-extension failure signals that PostgreSQL has exhausted available disk space. Check capacity before relying on deletes or maintenance operations to recover room. section 7.1
VACUUM FULL has a different trade-off. It can return reclaimed space to the operating system by rewriting the table, but it takes an ACCESS EXCLUSIVE lock for that work. The table is unusable during the operation, making it a hazardous emergency response for a busy production system. Track disk usage early instead of waiting for a crisis that invites destructive shortcuts. section 7.1
The practical default is preventative maintenance: leave autovacuum available, monitor disk capacity, and use VACUUM ANALYZE where reclaimed space and fresh statistics are both needed. Diligent vacuuming is part of maintaining PostgreSQL performance, stability, and reliability rather than a task to suppress whenever it becomes visible. section 6.7 section 11.4
