PromQL Query Cost Calculator

Estimate the computational cost and memory footprint of a PromQL range query from series matched, time range and resolution.

Inputs

Series Matched by Selectorseries

Number of time series the query's label selector matches.

Query Time Rangehours

Range vector duration, e.g. [24h] or the dashboard's overall time range.

Step / Resolutionseconds

Sample resolution/step used to evaluate the query (matches scrape interval for raw queries, coarser for downsampled queries).

Bytes per Sample (in memory)bytes

In-memory footprint per decoded sample during query execution — a float64 value is 8 bytes plus timestamp/overhead.

Query Cost (samples evaluated)

28,800,000

Estimated Query Memory

219.73MB

Cost Rating

Moderate — noticeable but usually acceptable

Samples per Series

5,760.0

Step by step

Samples per series: time range ÷ resolution
86400s ÷ 15s
= 5760.0 samples
Total samples evaluated (query cost)
5000 × 5760.0
= 28,800,000 samples
Memory footprint: samples × bytes/sample
28,800,000 × 8 bytes
= 219.73MB

How it works

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.

Formula

query_cost = series_scanned × time_range_seconds × bytes_per_sample

series_scanned: Number of time series the query touches
time_range_seconds: Duration of the query lookback window (seconds)
bytes_per_sample: Average bytes per data point scanned

Frequently Asked Questions

Why do broad label selectors matter so much for cost?

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.

What's the best fix for an expensive, frequently-run query?

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.

Does resolution/step affect accuracy, not just cost?

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.

Do aggregation functions like `sum()` reduce this cost?

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.

You might also need

Dashboard Query Time Calculator Metrics Cardinality Calculator Grafana Dashboard Load Calculator