2/ Downsampling is the ability to reduce the rate of a signal, reducing the resolution and size of data. It helps you to store data more cheaply and query it faster.

3/ In the Prometheus ecosystem, downsampling is usually done through recording rules. They are easy to use and speed up long-term queries. We even support them in Promscale! prometheus.io/docs/prometheu…

4/ But recording rules have limitations: 1️⃣ Data is delayed by the time needed to aggregate it (for a 1 hour resolution, results will be stale by 0-60mins). 2️⃣ They don’t necessarily help with reducing storage costs, since not all systems offer per-metric retention policies.

5/ Limitations cont’d: 3️⃣ We risk inaccurate results if we want to aggregate larger buckets of data (average of averages, aggregating histograms). 4️⃣ They’re only applied to data received after the rule is created and require additional manual steps to backfill data.

6/ 🔥 Today we release in beta an additional downsampling method in Promscale called continuous aggregation. This new method is more timely and accurate than recording rules for many cases.

7/ Promscale continuous aggregates leverage a TimescaleDB feature of the same name to have the database (@TimescaleDB) manage data materialization and downsampling for us. Combined, these two methods cover the majority of downsampling use-cases. docs.timescale.com/timescale…

8/ Continuous aggregations address the following limitations of recording rules: ✅ Timeliness ✅ Rollups ✅ Query flexibility for retrospective analysis ✅ Backfilling

9/ Which method should you use? Here’s what to consider: 1️⃣ Access to recent data: For operational or real-time uses, use continuous aggregates. You benefit from real-time aggregates which combine materialized and raw data for up to date results more efficiently.

10/ 2️⃣ Size of the time-bucket: Continuous aggregates are better when aggregating more data points together (1 hour or more of data), while recording rules are better for small buckets.

11/ 3️⃣ Number of metrics in materialization: Continuous aggregates can only be defined on a single metric. If you need to materialize queries on more than one metric, use recording rules.

12/ 4️⃣ Query flexibility: If you know the exact queries that will be run on the materialization, recording rules may be more efficient. However, if you want flexibility, continuous aggregates can answer more queries based on the materialized data.

13/ 5️⃣ Access to old data: If you need old data points to also be aggregated as soon as downsampling for a metric is configured, continuous aggregates would be a better choice, since recording rules require additional steps to backfill data

14/ ➡️ Read on to learn more about continuous aggregates in Promscale, how to set them up, how to query them and how to decide when to use continuous aggregates and when to use Prometheus recording rules: tsdb.co/promscale-downsampli…

15/ 🗣️ Promscale continuous aggregates are currently in beta and we are actively looking for feedback from the community to help us make it better. Share your feedback in this Github discussion 👉 tsdb.co/prom-downsampling-fe…

16/ To start getting more value out of your traces and metrics, try Promscale for free today: tsdb.co/github-promscale