The person who owns the ingest pipeline gets no line item for any of this. What arrives instead is a p95 that drifts up about 3 ms a week and a nightly VACUUM that takes a bit longer than last month's [4]. In Timescale's sample output, device_metrics_08 reports 22.33% dead tuples across 68 GB of total relation size, with a vacuum that ran minutes earlier [14]. Take the tuple ratio at face value and about 15 GB of that table is space a sequential scan walks at full price (0.2233 x 68 GB = 15.2) [22][3].
Treat 15 GB as a ceiling rather than a measurement. pg_total_relation_size includes indexes, and the live and dead counts are estimates from the cumulative statistics system, which pg_stat_reset() sets back to zero [12]. The byte-exact figure needs pgstattuple, which reads every page and refuses to run against a partitioned parent, so it has to be aimed at a leaf [13]. And n_ins_since_vacuum, the column that separates "ingest is outrunning vacuum" from "nothing has been near this table", only exists on PostgreSQL 13 and later [6].
The freeze cadence is scheduled arithmetic. The insert trigger fires at autovacuum_vacuum_insert_threshold plus autovacuum_vacuum_insert_scale_factor times the row count, defaults of 1,000 and 0.2 [8], so a 500-million-row partition crosses at 100,001,000 inserts [10] and, at 50,000 inserts per second, does that every 2,000 seconds [11]. Timescale rounds it to roughly 100 million inserts, or half an hour [9]. The period is governed by how many rows the partition holds rather than by how much of it changes, and the freezing work produces no dead tuples of its own [7][28].
That is why the percentage alone makes a poor alert. Timescale's instruction is to read the ratio beside last_autovacuum [21]. trades_2026_07 is the biggest table in the sample at 122 GB and sits at 0.23% dead with a fresh timestamp, which the guide reads as the do-nothing case [17][18]. events_raw sits at 12.93% and has logged 3,390 autovacuum runs against trades' 2,214, on about 28% of the size [16][25]; Timescale calls that band the equilibrium of a busy append-only table, holding the line with no headroom for a traffic spike [19]. The audit_log row is a different animal: dead tuples outnumber live by roughly 2.4 to 1 [23], the vacuum that last touched it ran more than three days before the others [24], and its insert count since then falls below even the 1,000-row floor in the trigger formula, so ingest volume will not summon a vacuum there [26].
The grid worth putting on a dashboard, then, has dead_pct on one axis and last_autovacuum freshness on the other, with autovacuum_count as the trend line. A low ratio with a fresh vacuum needs nothing. A ratio climbing past 20% with a fresh vacuum means autovacuum is running and still losing ground, which is where settings work belongs [20]. A high ratio with a stale timestamp is a different investigation, because something is keeping vacuum from running and insert volume will not restart it [26]. Which cell a table lands in decides whether Monday goes to autovacuum tuning or to finding out what is holding vacuum off.
