Dead-row pressure
Maintenance audit
Postgres autovacuum health check for drift and dead rows
PostgresAudit reviews autovacuum health from read-only PostgreSQL statistics, highlighting dead-row pressure, stale maintenance timestamps, and tables that need human planning.
Autovacuum drift
Analyze freshness
Maintenance history review
Dead rows and stale maintenance
The check compares estimated live rows, estimated dead rows, last vacuum, last autovacuum, last analyze, and table size to identify tables where maintenance may be falling behind.
Bloat signals without unsafe claims
PostgresAudit can flag bloat signals and relation growth patterns, but it does not claim exact reclaimable space unless the collected evidence supports that level of detail.
Autovacuum drift diagnosis
Tables with old autovacuum or analyze timestamps, high dead-row ratios, or heavy write activity become review candidates for threshold, scale factor, and scheduling analysis.
No automatic VACUUM
The product stays read-only. It does not run VACUUM, change autovacuum settings, or perform repairs. Findings are meant to support a planned maintenance decision.
Related topics
RelatedLinks for neighboring audit problems
Use these focused guides to compare query pressure, index decisions, and maintenance signals before you change production.
FAQ
Frequently asked questions
These answers stay inside the current PostgresAudit product boundary: read-only collection, evidence-gated findings, and human-reviewed next steps.
Does PostgresAudit run VACUUM or VACUUM FULL?
No. It only reads statistics and reports maintenance candidates. Any vacuum command, lock-risk review, or configuration change stays with the database owner.
What is autovacuum drift?
Autovacuum drift means table changes appear to outpace maintenance signals, such as rising dead rows, old vacuum timestamps, or stale analyze data on important tables.
Can dead rows explain slow queries?
They can contribute, especially with larger tables and stale planner statistics. The report treats dead rows as one signal alongside table size, scan behavior, and query evidence.
What should teams do after a high-risk finding?
Review table workload, confirm planner statistics, inspect maintenance history, estimate lock and I/O risk, then schedule the safest manual maintenance path.