Downsampling (rollup)

Keeping recent metrics in fine detail while compressing older history into wider time buckets.

downsamplngmake old metrics less detailedkeep minute data then turn it into hourly datashrink historical monitoring datastop storing every datapoint forevermetrics getting blurrier as they ageroll up old time seriesmy metrics storage bill keeps climbing

See it

Live demo coming soon

What it is

Downsampling, often called a rollup, replaces old high-resolution metric samples with summaries in wider time buckets. Ten-second points might become five-minute rows, then hourly rows, keeping sum, count, minimum, and maximum instead of every original value. RRDtool's round-robin archives did exactly this in the 1990s; TimescaleDB continuous aggregates are one modern way to build those tiers.

Reach for it when historical trends matter but second-by-second history does not justify its storage and query cost. Keep recent data sharp for incident work, then retain coarser data for capacity planning and year-over-year comparisons.

Gotcha: a rollup throws information away. Derive averages from stored sum and count, never by averaging averages, and do not average percentile values together. Refresh each rollup completely before deleting the raw range that feeds it.

Ask AI for it

Add metric downsampling in TimescaleDB. Keep raw ten-second samples for 30 days, create five-minute and one-hour continuous aggregates with time_bucket, and store sum, count, min, and max for each metric and label set. Derive averages from sum divided by count. Schedule refreshes with add_continuous_aggregate_policy, then use add_retention_policy so raw rows are removed only after both rollups cover them. Keep five-minute data for 180 days and hourly data for two years, and add tests for late samples and bucket boundaries.

You might have meant

metricsamplingtelemetryhigh cardinalitylatency percentile