Vacuum Frequency Calculator

Work out vacuum frequency instantly with clear inputs, formula shown and shareable results.

About Vacuum Frequency Calculator

PostgreSQL's MVCC leaves a dead tuple behind every update and delete, and autovacuum triggers when dead tuples exceed a scale factor of the table size. On a large hot table the default 20 percent means hundreds of millions of dead rows accumulate first, so the threshold is usually lowered for such tables — the duty cycle here shows whether continuous vacuuming is the result.

Formula

Vacuum cadence

dead tuples at trigger = rows x threshold; interval = trigger / churn rate; duration = rows / vacuum throughput; duty cycle = duration / interval

Worked example

With the default values below, Vacuum Frequency Calculator returns Hours between vacuum runs of 11.11. Change any input above and every figure here is recalculated in your browser.

Inputs used

Rows in the tableminimum 1: 80,000,000
Updates and deletes per secondminimum 0.001: 400
Dead-tuple thresholdaccepts 1–100 %: 20 %
Vacuum throughputminimum 1: 200,000

Results

Hours between vacuum runs: 11.11 h
Dead tuples at the trigger point: 16,000,000
Vacuum duration: 400 s
Share of time spent vacuuming: 1.00%

Step by step

1Values used
2Vacuum cadence
3Hours between vacuum runs= 11.11 h
4Dead tuples at the trigger point= 16,000,000
5Vacuum duration= 400 s
6Share of time spent vacuuming= 1.00

Assumptions and limits

The result is derived only from the 4 inputs listed above. Anything not among them is not part of the calculation.
In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
Figures are rounded for display to 2 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

Frequently Asked Questions

Why lower the scale factor on big tables?

Because 20 percent of 80 million rows is 16 million dead tuples, which bloats the table and slows every scan long before vacuum runs. A fixed threshold or a much smaller scale factor keeps bloat bounded.

What is transaction ID wraparound?

If vacuum never freezes old tuples, the transaction counter can approach wraparound and PostgreSQL will refuse writes. Monitoring the oldest unfrozen transaction age is essential on high-churn systems.