Reading Autovacuum Like a Quiet Letter

Autovacuum sits at an awkward intersection: it is partly housekeeping, partly garbage collection, and partly a quiet conversation between the storage layer and the planner. Operators tend to inherit autovacuum settings, never quite trust them, and then spend a year cautiously experimenting until something feels right. The result is fragile knowledge — a stack of small tweaks that nobody can explain to the next person who joins the team.

In our Day-Two PostgreSQL cohort we treat autovacuum as a single, readable narrative: a table accumulates dead rows, autovacuum notices, autovacuum visits, and the planner gets honest visibility numbers again. Once you can describe that loop in two sentences, the parameters start to fit a story rather than a checklist. autovacuum_vacuum_scale_factor controls when the visit happens; autovacuum_vacuum_cost_limit controls how aggressively it works once it starts.

A useful first audit: pick three of your busiest write tables and look at last_autovacuum and n_dead_tup in pg_stat_user_tables. If the gap between visits is measured in days for tables with millions of writes per hour, that is your conversation starter — not a problem to fix at midnight, but a thread to pull on during a calm afternoon. The rule we keep coming back to is: tune for the tail, not for the average.

None of this requires brave configuration changes. Most teams we work with end up with two or three table-level overrides and an unchanged default elsewhere. The boring outcome is the right outcome.