The Janitor
Autovacuum is a background daemon that PostgreSQL runs automatically. It wakes up periodically, inspects tables to see if they need cleaning, and dispatches worker processes to run the VACUUM and ANALYZE commands. You do not invoke it manually — it runs on its own schedule, governed by configuration parameters.
Autovacuum has three distinct jobs, each critical in its own right:
1. Recover Space (Dead Tuple Removal)
Autovacuum scans the table and marks dead tuples as free space in the Free Space Map (FSM). This space becomes available for future INSERT operations to reuse. Critically, standard autovacuum does not shrink the physical file on disk — it just makes the space reusable internally. The OS-level file size stays the same.
2. Update Statistics (ANALYZE)
PostgreSQL's query planner decides how to execute a query (which index to use, whether to do a sequential scan) based on statistics about data distribution. Autovacuum runs ANALYZE to keep these statistics fresh. Stale statistics cause the planner to make bad decisions — for example, choosing a sequential scan on a 500 GB table when an index scan would be 1000x faster.
3. Prevent Transaction ID Wraparound
Every row in PostgreSQL is stamped with the Transaction ID (XID) of the transaction that created it. XID is a 32-bit counter, which means it wraps around after approximately 4 billion transactions. If a row's XID is older than the current XID by more than 2 billion, PostgreSQL can no longer determine whether that row is visible — it becomes confused about past and future. To prevent this, autovacuum freezes old rows, replacing their XID with a special "frozen" marker that is always considered visible. If autovacuum falls too far behind on freezing, PostgreSQL will shut down and refuse all connections until a manual VACUUM FREEZE is run. This is one of the most catastrophic failure modes in PostgreSQL operations.
The Default Failure Mode
The default autovacuum configuration was designed for small databases on modest hardware — think a 10 GB application database on a shared server. On a modern production system with terabytes of data and thousands of writes per second, the defaults are dangerously conservative. Autovacuum won't trigger often enough on large tables, and when it does trigger, it throttles itself so aggressively that it cannot keep pace with the incoming write rate. The result is runaway bloat.
Interviewers frequently ask: "What happens if autovacuum can't keep up?" The answer has two layers. First, bloat accumulates, causing query slowdowns and disk exhaustion. Second — and this is the senior-level answer — if autovacuum falls behind on freezing, PostgreSQL will eventually enter "autovacuum wraparound protection" mode, which forces an aggressive VACUUM FREEZE on every table and can cause severe I/O contention. In the worst case, PostgreSQL shuts down entirely to prevent XID wraparound corruption. Mention both layers.