At a glance
Top Tables by Dead Tuples ranks your tables by the number of dead row versions (n_dead_tup) currently waiting to be reclaimed. EveryUPDATEandDELETEin PostgreSQL leaves behind a dead tuple that autovacuum must clean up; a hot table accumulating dead tuples faster than autovacuum clears them is the textbook signal that autovacuum needs tuning for that table. Left unchecked, dead tuples become table bloat, which slows scans and wastes disk.
What it tracks
The card readsn_dead_tup from pg_stat_user_tables and lists the tables holding the most dead tuples, refreshed in real time (RT). A dead tuple is a row version made obsolete by an UPDATE or DELETE but not yet reclaimed by VACUUM; PostgreSQL’s MVCC model keeps these around until no transaction can still see them, after which autovacuum frees the space for reuse. A table near the top of this list with a high and rising dead-tuple count is one where write churn is outpacing autovacuum, which means per-table autovacuum tuning is needed: a lower autovacuum_vacuum_scale_factor, a higher autovacuum_vacuum_cost_limit, or both, so the table is vacuumed more aggressively. The downstream effects are bloat (the table occupies more disk than its live rows justify), slower sequential and index scans, and pressure on the figures behind Oldest Autovacuum Age (hours) and Database Disk Usage %. This is an Autovacuum & Bloat card with no alert threshold of its own; it is a diagnostic ranking you reach for when the autovacuum-age or health-score cards flag a problem. Pair it with PostgreSQL Health Score, whose autovacuum factor this data feeds.
Reconciling against the source
Reconcile against PostgreSQL’s own tooling withSELECT relname, n_dead_tup, n_live_tup, last_autovacuum FROM pg_stat_user_tables ORDER BY n_dead_tup DESC;. On managed services, the same query runs over a normal connection; RDS / Aurora Performance Insights and Cloud SQL system insights also surface per-table dead-tuple and vacuum activity.