/demo

Five tables

Each one is a real report built from a real snapshot payload: the same route, the same formulas, the same sliders you would get from your own table. They are here because vacuum problems come in a small number of shapes, and reading five of them is faster than reading the documentation.

Two of the five cannot be fixed by any setting on the page. That is deliberate.

events.event_log
prod-eu-1
SHAPE
scale factor never revisited

The default 0.2 scale factor on a 412 M-row table. Nobody set it wrong; nobody set it at all.

HEAP
14.3 GB
LIVE
412.34 M
DEAD
3.15 M · 0.76%
public.sessions
prod-eu-1
SHAPE
fillfactor 100, no HOT updates

A table where the vacuum settings are not the problem. The fix is fillfactor.

HEAP
9.7 GB
LIVE
18.40 M
DEAD
9.10 M · 49.47%
analytics.page_views_2026_07
prod-eu-1
SHAPE
append-only, never vacuumed

Dead tuples are irrelevant here. The whole report is the freeze horizon.

HEAP
80.6 GB
LIVE
1.90 B
DEAD
41.0 k · 0.00%
public.job_queue
prod-eu-1
SHAPE
xmin horizon pinned

The state no setting fixes. Every slider here is already correct.

HEAP
3.4 GB
LIVE
84.1 k
DEAD
3.14 M · 3734.61%
billing.invoices
prod-eu-1
SHAPE
already correct

A tuned table. The report says so and proposes nothing, which is the result most tools refuse to give.

HEAP
4.9 GB
LIVE
41.21 M
DEAD
782.1 k · 1.90%
→ build one from your own tablebrowse the terms
1Each card holds a snapshot payload of the kind the query produces, and opening one loads the ordinary report route. Anything that renders wrong here renders wrong for a real table.
2Table and database names are invented; the statistics are shaped after production tables of that kind. Nobody's data is in here, which is also why the numbers are round enough to check by hand.
Five tables — robovac