From 7c9803ce8da462a9f2a435a6c4e0068d601421ac Mon Sep 17 00:00:00 2001 From: Jeff Larson Date: Sat, 4 Jul 2026 22:16:02 -0700 Subject: [PATCH] migrations: durable aggressive autovacuum for telemetry tables The telemetry DB grew to 77 GB of dead-tuple bloat. The 7-day retention prune deletes rows fine, but at Postgres' default 20% autovacuum scale factor, autovacuum effectively never fired on the high-churn tables (logs, metric_series_rollups, spans): their insert+delete churn never crossed the 20%-of-table threshold, so dead tuples were never reclaimed. Lower the vacuum (and insert-triggered vacuum) scale factor to 2% and raise the cost limit so autovacuum keeps up with the prune's delete churn. These settings were already applied live via ALTER TABLE; this migration makes them durable across a DB recreate. Co-Authored-By: Claude Opus 4.8 Claude-Session: https://claude.ai/code/session_013cYVqzH7Xfwea7fAozdQK7 --- .../migrations/0013_telemetry_autovacuum.sql | 28 +++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 server/migrations/0013_telemetry_autovacuum.sql diff --git a/server/migrations/0013_telemetry_autovacuum.sql b/server/migrations/0013_telemetry_autovacuum.sql new file mode 100644 index 0000000..f14aebe --- /dev/null +++ b/server/migrations/0013_telemetry_autovacuum.sql @@ -0,0 +1,28 @@ +-- Aggressive per-table autovacuum for the high-churn telemetry tables. The 7-day +-- retention prune deletes rows fine, but at Postgres' default 20% vacuum scale +-- factor autovacuum effectively never fired on logs, metric_series_rollups, and +-- spans — their steady insert+delete churn never crossed the 20%-of-table +-- threshold before the table itself had grown, so dead tuples were never +-- reclaimed and the DB ballooned to 77 GB of bloat. Lowering the scale factor to +-- 2% (and matching the insert-triggered vacuum) makes autovacuum run often enough +-- to keep up with the prune's delete churn, and the raised cost limit lets each +-- run actually make progress instead of throttling to a crawl. These were applied +-- live via ALTER TABLE; this migration makes that tuning durable across a DB +-- recreate. +ALTER TABLE logs SET ( + autovacuum_vacuum_scale_factor = 0.02, + autovacuum_vacuum_cost_limit = 2000, + autovacuum_vacuum_insert_scale_factor = 0.02 +); + +ALTER TABLE metric_series_rollups SET ( + autovacuum_vacuum_scale_factor = 0.02, + autovacuum_vacuum_cost_limit = 2000, + autovacuum_vacuum_insert_scale_factor = 0.02 +); + +ALTER TABLE spans SET ( + autovacuum_vacuum_scale_factor = 0.02, + autovacuum_vacuum_cost_limit = 2000, + autovacuum_vacuum_insert_scale_factor = 0.02 +);