# Tag everything. Query all of it.

Every metrics vendor eventually asks you to pick which tags are worth keeping. That question only exists because their storage charges by unique series. CtrlB stores metrics as columns in Parquet, so a dimension costs what its bytes cost.

## Metadata

- **Canonical HTML**: https://ctrlb.ai/solutions/metrics-at-scale
- **Section**: Solutions — Infinite cardinality metrics

## At a glance

| Figure | What it refers to |
|--------|-------------------|
| 100M+ series | On object storage |
| 0 drop rules | Nothing to configure away |
| Every tag | Stays queryable |
| Bytes, not series | What cost tracks |

## The cardinality tax

- Traditional metric pricing counts unique tag combinations, so adding a tenant or user dimension multiplies your bill rather than your storage.
- The mitigation vendors offer is an allowlist or blocklist of tags — you still decide upfront which context to discard, you just do it in a config file.
- By the time an incident needs the dimension you dropped, the data to reconstruct it is gone.
- Teams end up not instrumenting the workflows that matter most, because the interesting ones are the high-cardinality ones.

## What removing it looks like

- Tag by user, tenant, device, region, endpoint, or LLM call. There is no allowlist to maintain because no tag needs permission to exist.
- Series are columns in Parquet, not rows in a TSDB index, so a new dimension adds bytes rather than multiplying a series count.
- Every historical tag stays queryable, so the dimension you did not think to prioritise is still there during the incident.
- Cost tracks the data you wrote and the compute you used — the same drivers as the rest of your infrastructure bill.

## How it works

1. **Write metrics with every dimension** — Emit the tags that describe your system honestly — per tenant, per model, per execution path — without pre-registering them or estimating their cardinality first.
2. **Store as columns, not series** — Metrics land in the same Parquet lake as logs and traces. High-cardinality tags compress as columns instead of exploding an in-memory index.
3. **Slice by anything, later** — Group by a dimension you never planned to group by. The query reads the columns it needs; nothing had to be indexed in advance for it to work.

## Capabilities

- **No cardinality ceiling**: There is no series limit to hit, so there is no throttling, sampling, or surprise overage when traffic changes shape.
- **No tag configuration**: No allowlists, no blocklists, no drop rules, and no thirty-day window deciding which tags survive.
- **Per-tenant and per-user views**: The dimensions that make support and billing questions answerable are exactly the ones cardinality pricing punishes.
- **AI workload dimensions**: Tag by model, prompt path, and execution route — the shape of AI systems is high-cardinality by nature.
- **Same lake as logs and traces**: A metric anomaly and the logs behind it are one query apart, not one tool apart.
- **Cost you can predict**: Bytes written and compute used, with no multiplier for how descriptively you tagged.

## FAQ

**Is there really no limit?**

There is no per-series limit in the pricing or the index. The practical bound is the storage the data occupies and the compute a query over it consumes — both of which scale linearly and predictably.

**How is this different from Metrics without Limits?**

That approach separates ingestion from indexing and asks you to configure which tags stay queryable. CtrlB keeps every tag queryable because there is no separate index whose size drives the bill.

**Do high-cardinality queries stay fast?**

Yes. Columnar layout means a query reads only the dimensions it references, so adding unused tags to a metric does not slow down queries that ignore them.

**Can we keep our existing dashboards?**

Yes — CtrlB can sit under the metrics tooling you already use.

Markdown mirror: fetch `/solutions/metrics-at-scale.md` for this page as plain Markdown.