last_vacuum

The last_vacuum metric tracks the timestamp of the most recent vacuum operation performed on PostgreSQL tables, whether triggered manually or by the autovacuum daemon. VACUUM is a critical PostgreSQL maintenance operation that reclaims storage occupied by dead tuples (obsolete row versions created by UPDATE and DELETE operations), prevents transaction ID wraparound issues, and updates table statistics for the query planner. This metric provides operational visibility into whether tables are receiving necessary maintenance, as PostgreSQL's MVCC (Multi-Version Concurrency Control) architecture continuously generates dead tuples during normal operations that must be cleaned up to maintain database health.

From an operational and reliability perspective, monitoring last_vacuum is essential for preventing several critical failure modes. Tables that haven't been vacuumed recently may experience table bloat (excessive disk usage), degraded query performance due to scanning unnecessary dead tuples, and in extreme cases, transaction ID wraparound which can force PostgreSQL into emergency shutdown mode. Healthy patterns typically show vacuum operations occurring within hours to days depending on table update frequency and autovacuum configuration. High-traffic tables with frequent UPDATEs or DELETEs should show recent vacuum timestamps (within hours), while read-mostly tables may show longer intervals without concern.

Common alerting use cases include triggering warnings when tables exceed organization-defined thresholds (e.g., no vacuum in 7+ days for active tables, or 30+ days for any table), which may indicate autovacuum isn't keeping pace with write workload or has been improperly disabled. Troubleshooting scenarios often involve correlating stale last_vacuum timestamps with performance degradation, investigating whether autovacuum is blocked by long-running transactions (visible in pg_stat_activity), or determining if autovacuum settings like autovacuum_vacuum_scale_factor need tuning. This metric is particularly valuable for cost management as table bloat from inadequate vacuuming directly translates to wasted storage costs and can necessitate expensive VACUUM FULL operations that require exclusive table locks.

The last_vacuum metric is your early warning system for some of PostgreSQL's most insidious performance issues—from bloat accumulation to the dreaded transaction ID wraparound. While many teams only think about vacuum when things go wrong, the real experts know that understanding when and why tables were last vacuumed reveals critical patterns about database health, autovacuum effectiveness, and potential resource bottlenecks before they impact users.

Our curated knowledge base brings together authoritative guidance from PostgreSQL core documentation, battle-tested troubleshooting strategies from teams running Postgres at scale, and workload-aware tuning recommendations that go far beyond default settings. Whether you're debugging why autovacuum isn't keeping up, trying to prevent transaction ID exhaustion, or optimizing vacuum schedules for your specific workload patterns, we've assembled the essential resources that SREs and database engineers rely on to keep PostgreSQL running smoothly. Discover how to interpret vacuum timing data, tune autovacuum parameters with confidence, and recognize the warning signs that warrant immediate attention.