Resolution requirements across query ranges
A dashboard showing the last fifteen minutes may need every original sample because a short spike or counter reset can change the result. The same panel viewed across ninety days cannot display that resolution. Thousands of raw points are eventually reduced into each pixel column, even if the backend spends time reading and processing all of them first.
Rollups address that mismatch by storing pre-aggregated windows alongside raw samples. ClickHouse® database materialised views can maintain those windows as data arrives, moving repeatable aggregation work from query time to ingestion time. A long-range query can then read a much smaller representation when the rollup contains the information needed by the PromQL function.
The size reduction can be substantial, but a smaller table is not automatically a correct source. The query layer has to understand both the requested resolution and the semantics of the expression before it can decide that a rollup is safe to use.
Rollup eligibility in the query planner
Choosing the wrong rollup can make a query fast and wrong. A table containing hourly averages cannot reproduce a maximum, and a counter calculation needs enough information to handle changes and resets across the requested window. The coarsest available table is therefore not always the most efficient valid table.
PulsusDB plans the PromQL expression before generating SQL. It knows the query range, evaluation step, selector windows and functions applied to each branch. That information lets the planner reject a rollup whose resolution is too coarse or whose stored aggregate state cannot support the downstream operation.
Recent data also presents a boundary problem because a completed historical rollup may end before the query does. For eligible expressions, the generated plan can read the historical portion from a rollup and splice it together with recent raw samples. The PromQL evaluator still receives a continuous input across the complete requested range.
Source selection behind the Prometheus API
Maintaining separate dashboards for raw data, hourly aggregates and long-term history exposes a storage decision through the client interface. It also creates duplicated queries and makes it easy for panels to disagree at the boundaries between data sources.
With automatic routing, the client sends the same PromQL expression whether it requests fifteen minutes or ninety days. PulsusDB chooses raw samples, one rollup or a plan that combines both, then exposes that decision through its query explanation rather than encoding it into a different metric name.
This keeps the external query contract stable while allowing the physical storage layout to evolve. New rollup resolutions can be introduced, retention can move older data to object storage and the planner can improve its cost decisions without requiring a corresponding rewrite of dashboards and API clients.