What is cardinality in metrics and why does high cardinality cause problems?

Cardinality in metrics refers to the number of unique label value combinations that a metric can produce. A metric like http_requests_total{method, status_code, endpoint} with 5 methods, 20 status codes, and 1,000 endpoints generates up to 100,000 unique time-series. Each unique combination is called a label set or series.

High cardinality causes problems in time-series databases like Prometheus because each unique series requires its own storage, indexing, and memory overhead. The Prometheus TSDB keeps an inverted index of all label values in RAM. When you add a label like user_id or request_id — which can have millions of values — the number of series explodes. This is called a cardinality explosion, and it can OOM-kill a Prometheus server within minutes.

Common cardinality pitfalls include: adding user IDs, session tokens, IP addresses, or UUIDs as metric labels; using unbounded string values as labels; or creating per-endpoint metrics for every URL path in an API (especially with path parameters like /user/{id}).

Solutions include: using logs or traces for high-cardinality data instead of metrics; normalizing high-cardinality labels into fixed buckets; using recording rules to pre-aggregate before storage; or migrating to backends that handle high cardinality better than vanilla Prometheus, such as VictoriaMetrics or Thanos.