What is High Cardinality in Observability?

High cardinality describes a field, label, or dimension with a very large number of unique values. In observability, cardinality is the count of distinct time series or distinct field values a system must track — and it is the single most common reason metrics systems fall over or observability bills explode.

Low vs high cardinality

Cardinality multiplies across labels: endpoint (100) × region (20) × status (60) is already 120,000 series from three innocent-looking labels.

Why high cardinality hurts

Time-series databases like Prometheus create a separate series (with memory-resident index entries) for every unique label combination. As unique combinations grow, memory usage balloons, queries slow, and ingestion stalls — the notorious “cardinality explosion.” See Prometheus data cardinality for the mechanics. Some commercial platforms turn the same problem into pricing: charging per custom-metric series makes per-customer labels financially, rather than technically, impossible.

The tension is that high-cardinality questions are the valuable ones: which tenant, which device, which deployment caused the regression. Aggregated dashboards can’t answer them.

Managing cardinality

• Keep unbounded values (user IDs, request IDs) out of metric labels; put them in logs and traces instead, where they belong
• Aggregate or drop labels you never query, at collection time
• Use recording rules / streaming aggregation for dashboard queries
• Choose storage engines that tolerate cardinality: columnar formats index nothing by default, so a high-cardinality field costs the same as any other column

High cardinality in OpenObserve

OpenObserve stores telemetry as columnar Parquet rather than per-series indexes, so high-cardinality fields in logs, metrics, and traces don’t cause memory explosions or per-series charges — you can keep user IDs and pod names queryable without redesigning your schema around the backend’s limits.