This piece is part of a series on high cardinality — what it means, where it shows up in real systems, how it affects your infrastructure and database operations, and why it’s worth embracing rather than looking for ways to minimize it.
You’ve probably seen the signs: slow dashboards, exploding label sets, rising storage costs, and queries that feel heavier than they should. The underlying issue often traces back to high cardinality — sometimes obvious, often not.
But before we get into the deeper challenges, let’s start with the basics.
Cardinality refers to the number of unique values or elements in a set. The higher the number of unique elements, the higher the cardinality.
Think of it this way: If you have a small box of crayons with just the primary colors (red, blue, yellow), that’s low cardinality — only three unique values. But if you have that giant 120-color crayon box with exotic names like “Mango Tango” and “Razzmatazz,” that’s high cardinality.
In databases and monitoring systems, cardinality refers to the number of unique values in a specific field or column.
Example:
- Low cardinality: The basic colors of the rainbow (VIBGYOR) — just 7 unique values.
- High cardinality: Hex color codes (#FFFFFF, #000000, etc.) — potentially 16.7 million unique values.
Similarly, if we consider ice cream flavors:
- Low cardinality: Common flavors like chocolate, vanilla, and strawberry.
- High cardinality: The thousands of unique flavor combinations possible at a custom ice cream shop.
In a database context:
- Low cardinality fields: Gender (typically few options), country codes, status indicators like “active/inactive.”
- Medium cardinality fields: Cities, product categories, age groups.
- High cardinality fields: Email addresses, user IDs, IP addresses, timestamps, session IDs.
For instance, in a user database, the “country” field might have at most 195 unique values, while the “user_id” field could have millions.
In monitoring systems, high cardinality creates operational challenges:
-
Prometheus handles metrics well — until cardinality spikes. In environments like Kubernetes, exploding label combos (user_id, pod_name, container_id) lead to slow queries, memory strain, and instability. And adding more hosts doesn’t magically fix it.
-
With Datadog, high cardinality increases costs, as each unique metric-tag combination counts as a separate time series. As cardinality grows, you may hit higher billing tiers, especially with custom metrics.
What Happens When Cardinality Gets Out of Hand?
High cardinality becomes a significant concern in large-scale systems, affecting performance in several technical areas, often in ways that aren’t immediately obvious during development.
You might recognize these symptoms:
- Dashboards timeout or fail to load when using filters like user_id, session_id, or feature_flag
- You see spikes in observability bills without any clear traffic increase
- You’ve had to drop labels in Prometheus or Datadog to avoid memory issues or hitting quotas
- Your monitoring tool warns you: “Too many time series.”
- You had to create a second monitoring system to manage noisy microservices
Now, let’s examine these challenges more closely.
Database Performance Challenges
When dealing with high cardinality data, databases can struggle with:
- Index size: More unique values mean larger indexes
- Query performance: Queries that filter on high cardinality fields may not benefit as much from indexes
- Storage requirements: More unique values often mean more storage space
A classic example is deciding whether to index a field like “gender” versus a field like “email_address”. Indexing the low cardinality “gender” field provides significant performance benefits since the database can quickly narrow down results. But indexing a high cardinality field like “email_address” might result in an index almost as large as the table itself, potentially reducing its efficiency.
Monitoring System Challenges
High cardinality has enormous implications for monitoring systems. This is where things can get really painful if you’re not careful.
When you tag or label metrics with high cardinality dimensions, you can end up with a combinatorial explosion of time series. For example, if you tag metrics with:
- 100 services
- 1,000 hosts
- 10,000 unique user IDs
You could potentially generate 1 billion (100 × 1,000 × 10,000) unique time series! This can cause:
- Storage issues
- Query slowdowns
- Higher costs
- System crashes
This is why monitoring systems often limit the cardinality of tags or labels they accept.
Data Science and ML Implications
In data analysis and machine learning, high cardinality can complicate how you prepare and model data.
-
Raw high cardinality fields are hard to use directly: For example, a “user_id” with millions of unique values doesn’t provide much value if fed directly into a model — it’s just noise. You need to transform it into something meaningful.
-
One-hot encoding: This turns each unique value (like every city name) into its own column. So, 10,000 cities = 10,000 new columns — mostly filled with zeros. It works, but it’s inefficient and bloats your data.
-
Feature engineering solutions:
- Feature hashing: Reduces the number of columns by applying a hash function, making it faster but with some trade-offs.
- Embeddings: Turns high-cardinality fields into compact vectors, which are much more efficient for deep learning models.
The Far-Reaching Consequences of High Cardinality
System Observability
The observability challenge of high cardinality affects the very tools we rely on to understand system behavior.
When monitoring systems encounter high cardinality dimensions, they produce alert fatigue — thousands of similar notifications trigger simultaneously, hiding critical signals within noise. This leads to alert fatigue among operations teams, who begin ignoring potentially important alerts.
Visualization systems suffer equally:
- Dashboard limitations: Dashboards become slow or timeout when rendering high cardinality metrics
- Complex troubleshooting: Root cause analysis becomes exponentially more difficult
- Limited historical data: High cardinality forces aggressive downsampling, restricting long-term analysis
This often leads teams to create separate monitoring systems when central tools can’t handle their cardinality needs.
Infrastructure Costs
High cardinality significantly impacts infrastructure costs in an exponential rather than linear relationship. This is especially true in time-series databases, where high cardinality workloads often necessitate vertical scaling since adding more nodes doesn’t address the fundamental data structure problem.
Organizations frequently encounter:
- Unexpected billing spikes: New high cardinality dimensions can cause sudden cost increases
- Network saturation: High cardinality queries generate larger result sets, consuming more bandwidth
- License cost implications: Many enterprise products base licensing on data volume or node count
Database Operations
Databases with high cardinality face a cascade of operational challenges that go beyond simple storage concerns.
For example, it can cause query plan instability, meaning your database’s strategy for fetching data can change unexpectedly, leading to performance issues. Optimizers struggle to keep up with high cardinality because they rely on statistics that can quickly become inaccurate or outdated. What worked efficiently yesterday might slow down today if the optimizer makes the wrong decision.
Other key impacts include:
- Memory pressure: High-cardinality aggregations can eventually force operations to spill to disk
- Backup inefficiency: Incremental backups become less effective with frequently changing high-cardinality columns
- Uneven data distribution: In distributed databases, high cardinality can create unbalanced shards and hot spots
Testing and Development
The development lifecycle becomes increasingly complex as cardinality grows. Local environments cannot simulate production cardinality, resulting in code that works in development but fails in production. This leads to:
- Schema evolution constraints: Changes become increasingly risky
- Code complexity: Applications must implement sophisticated caching and data access patterns
- Technical debt acceleration: Quick fixes for high cardinality issues become entrenched
Over time, innovation slows as teams become cautious about changes that might worsen cardinality issues.
The Dual Nature of High Cardinality
Up until now, high cardinality has been viewed primarily as a problem due to challenges like:
- Storage and Processing: More unique values mean more data to store and process
- Indexing Issues: Traditional database indexes lose effectiveness as cardinality increases, sometimes becoming almost as large as the table itself
- Memory Strain: In-memory operations can hit limits when dealing with too many unique values
- Slow Queries: Queries against high cardinality fields tend to take longer to execute
- Visualization Hurdles: Visualizing millions of unique values meaningfully is nearly impossible
However, this perspective misses the fundamental value of granular data in modern systems. High cardinality isn’t just noise — it’s what enables pinpoint troubleshooting, personalized user experiences, and meaningful insights in distributed systems.
The real question now isn’t “How do we reduce cardinality?” but rather,
“How do we make the most of the rich detail it provides?”
Here’s why high cardinality is worth embracing:
- Granular analysis: Get deeper insights into individual users, transactions, or events
- Personalization: Drive smarter recommendations and tailored user experiences
- Precise monitoring: Track specific services or requests to pinpoint issues faster
- Rich insights: More unique values lead to more valuable data and patterns
This is especially crucial as we integrate AI into our workflows. AI systems thrive on detailed, unique data points to identify patterns and make predictions. High cardinality provides the granularity needed for training more accurate models, fine-grained personalization, anomaly detection, and predictive analytics.
Rethinking High Cardinality
High cardinality isn’t just a problem or noise anymore — it’s a natural part of how modern systems and architectures operate. In fact, it’s become an essential characteristic of the granularity we need in today’s data-driven world.
With the right approach (and Last9 in tow), you can embrace high cardinality, working with your system’s natural state instead of fighting against it.
As Replit’s team aptly put it, “high cardinality can be a valuable signal when handled correctly.” The key lies in having the right tools to make sense of the noise.
In the upcoming articles in this series, we’ll explore why high cardinality doesn’t have to be seen as an issue and how you can turn it into a competitive advantage for your systems.