Estimate the computational cost of a PromQL query based on range and series selected.
PromQL query cost scales with cost = series_matched × time_range ÷ resolution — the total number of raw samples the query engine must load and process. Memory footprint follows directly: memory = total_samples × bytes_per_sample. Queries that select many series over long ranges at fine resolution (e.g. a broad regex selector over 30 days at 15s resolution) can require gigabytes of transient memory and multi-second execution — recording rules pre-compute these into a much smaller derived series.
query_cost = series_scanned × time_range_seconds × bytes_per_sample
Series matched multiplies directly into total cost — a selector like `{job="api"}` might match 50 series, while an unscoped `{__name__=~".+"}` could match millions, so tightening selectors is often the single highest-leverage optimization available.
Pre-aggregate it into a recording rule that runs once on a schedule and stores the result as a new, much lower-cardinality series — dashboards and alerts then query the cheap pre-computed series instead of re-running the expensive raw computation on every load.
Yes — coarser resolution (larger step) reduces cost but can miss short-lived spikes between sampled points; recording rules let you keep high evaluation frequency for accuracy while still making ad-hoc dashboard queries cheap.
They reduce the *output* series count, but the query engine still has to load and process every input sample before aggregating, so `sum(rate(...))` over many series is not meaningfully cheaper to *evaluate* than the ungrouped query — it just returns less data.