Modern data systems run quietly — until they don’t. One concept that separates teams who scale gracefully from those who scramble every quarter is high cardinality. Not glamorous. Not discussed enough in onboarding docs.
Yet it sits at the center of database performance, monitoring infrastructure, and the speed at which engineering teams can answer hard questions.
Defining Cardinality
Cardinality, at its core, refers to the number of unique values within a dataset column or attribute. A column storing a boolean — true or false — has low cardinality. Two possible values, full stop. Contrast that with a column holding user IDs for a platform with 40 million accounts. Each row likely holds a distinct value. That’s high cardinality.
The spectrum matters:
- Low cardinality — Gender fields, status flags, Boolean columns, day-of-week labels
- Medium cardinality — Country codes, product categories, HTTP status codes
- High cardinality — User IDs, session tokens, IP addresses, transaction IDs, email addresses, device fingerprints
None of these are inherently “bad.” The problem surfaces when high-cardinality data gets handled by systems that weren’t designed to accommodate it — or when engineers don’t account for it upfront.
Where High Cardinality Becomes a Performance Problem
1. Indexing in Relational Databases
SQL databases use indexes to speed up query lookups. An index on a low-cardinality column — say, a “status” field with three possible values — offers limited benefit. The query planner might skip it altogether and opt for a full table scan. But high-cardinality columns, like primary keys or email fields, make indexes genuinely useful. Query planners can narrow down results fast.
The tension? Indexes consume storage and slow down write operations. Every INSERT or UPDATE forces the database engine to update the relevant index structures.
On a table receiving millions of writes per hour, indexing a high-cardinality column creates real overhead. The tradeoff isn’t hypothetical — it shows up directly in write latency and disk I/O metrics.
2. Time-Series Databases and Metric Explosion
This is where high cardinality gets expensive fast. Time-series databases like Prometheus store data as streams of timestamped values, each identified by a unique combination of label key-value pairs. The total number of distinct label combinations is called cardinality in this context, and it maps directly to memory usage.
Add a label like user_id to a Prometheus metric — suddenly, every active user spawns a new time series. 500,000 active users? Half a million unique series, all consuming RAM. This is the “cardinality explosion” problem that crashes Prometheus deployments and sends infrastructure bills through the roof.
Grafana’s documentation on Loki and cardinality covers this extensively, and it’s worth reading before designing any observability pipeline from scratch.
High Cardinality in Observability — A Distinct Challenge
Traditional monitoring tools were architected around aggregation. Pre-compute averages. Store rollups. Sacrifice detail to preserve performance. For a long time, that tradeoff made sense.
Then distributed systems happened. Microservices. Kubernetes. Hundreds of pods running the same service, each with a unique pod name, node, region, and deployment version.
Correlating a latency spike to a specific pod, request path, customer tier, and deploy SHA — that requires high-cardinality data. Aggregated dashboards can’t answer that question. They tell you something is slow. Not why, not for whom, not since when exactly.
Tools built for high-cardinality observability — Honeycomb being the most cited example — store raw events and query them dynamically. No pre-aggregation. The tradeoff is storage cost and query complexity, but the debugging capability is categorically different.
Engineers can slice event data by any combination of fields — user plan tier, geographic region, API version, request size — without having pre-decided those dimensions at instrumentation time.
High Cardinality in Machine Learning
Feature engineering decisions carry cardinality consequences that ripple forward into model training time, memory consumption, and prediction accuracy.
Categorical features with high cardinality — postal codes, product SKUs, merchant names — break naive one-hot encoding strategies.
One-hot encoding a feature with 50,000 unique values produces a 50,000-column sparse matrix. Most tree-based models handle this poorly without cardinality-aware encoding strategies.
Techniques worth knowing:
- Target encoding — Replace category with the mean target value for that category, calculated on training data only (with careful cross-validation to prevent leakage)
- Embedding layers — Neural network approach; map each category to a dense low-dimensional vector, learned during training
- Frequency encoding — Replace category with how often it appears in the dataset; useful when frequency correlates with the target
Google’s Machine Learning Crash Course touches on feature representation strategies that address this directly.
Why High Cardinality Matters More Now Than Five Years Ago
Three compounding shifts explain the increased urgency:
Data volumes are larger. Systems that generated megabytes per day now generate gigabytes per hour. High-cardinality columns at higher volumes don’t just scale linearly — the combinatorial explosion of unique value combinations grows faster than the underlying data.
Observability expectations have shifted. Teams now expect to debug production issues in minutes, not hours. That speed relies on querying high-cardinality telemetry data in real time. Legacy monitoring infrastructure, built before this expectation existed, simply wasn’t designed for it.
Multi-tenant SaaS architectures amplify the problem. Every customer, every tenant, every workspace becomes a distinct dimension. What worked for one customer base of 1,000 breaks at 100,000.
Practical Design Decisions for Managing High Cardinality
Teams that handle this well don’t eliminate high-cardinality data — they make deliberate choices about where it lives and how it gets queried.
- Separate high-cardinality attributes from metric labels. Store user_id in event logs or traces, not as a Prometheus label. Aggregate at the metric layer; enrich at the trace layer.
- Use columnar storage for analytics workloads. Systems like ClickHouse, BigQuery, or Redshift handle high-cardinality analytical queries dramatically better than row-oriented databases.
- Set cardinality limits in monitoring pipelines. Prometheus supports
sample_limitandlabel_limitconfigurations to prevent runaway cardinality from destabilizing the entire scrape pipeline. - Audit label sets regularly. Engineering teams frequently add labels during incident response and forget to remove them. That debt compounds.
- Profile before indexing. Not every high-cardinality column needs an index. Query patterns should drive indexing decisions, not column uniqueness alone.
The Organizational Cost Nobody Talks About
High cardinality isn’t only a systems problem. It carries an organizational cost.
When monitoring infrastructure collapses under cardinality load, on-call engineers lose visibility precisely when they need it most — during incidents. Debugging slows down. Mean time to resolution climbs.
Customer-facing reliability suffers. The root cause isn’t the incident itself; it’s the tooling that couldn’t handle the data shape the system was producing.
Teams that invest in cardinality-aware infrastructure — both in storage systems and observability tooling — consistently report faster incident response times. That translates directly to better uptime, less engineer burnout, and reduced operational cost over time.
Conclusion
High cardinality isn’t a niche database concept for specialists. It cuts across observability, machine learning, backend performance, and infrastructure cost.
The teams building resilient, fast, and debuggable systems in 2025 treat cardinality as a first-class design consideration — not an afterthought discovered when something breaks.
Build for it early. The cost of retrofitting cardinality-aware architecture into a system already in production is, without exception, far higher than designing for it on day one.
Also Read:
