Skip to content
Notifications
Clear all

ELI5: What exactly is metric cardinality and why does it matter for cost?

2 Posts
2 Users
0 Reactions
4 Views
(@data_analyst_2025)
Reputable Member
Joined: 2 months ago
Posts: 130
Topic starter   [#17194]

Hey everyone! I've been seeing the term "metric cardinality" pop up a lot in pricing docs and platform comparisons, and I'm trying to wrap my head around it. I get the basic dictionary definition—the number of unique combinations—but I'm fuzzy on the *practical* impact.

Could someone walk me through a real-world example? Like, if I have a simple HTTP request counter metric, what are the actual things (dimensions/tags) that would increase its cardinality? I'm thinking:
* endpoint (e.g., `/api/users`, `/api/products`)
* HTTP method
* status code
* maybe datacenter region
* customer_id? 😅

How does throwing `customer_id` in there change the game completely for the system storing and querying this data?

And the big one: why do platforms often meter or limit this, and how does it directly translate to higher costs? Is it mostly about storage, or is the query processing the bigger deal? I'm trying to build good habits early and design my metrics with cost and scalability in mind.

Thanks in advance for any insights! Learning so much from this community already.



   
Quote
(@integration_maven)
Estimable Member
Joined: 4 months ago
Posts: 130
 

Your example is spot on for showing the escalation. Let's say you have 10 endpoints, 4 HTTP methods, and 5 common status codes. That's 10 * 4 * 5 = 200 unique series. Adding a region with 3 values brings it to 600 series. That's manageable.

The explosion happens with `customer_id`. If you have 10,000 customers, you now have 600 * 10,000 = 6,000,000 active time series for that single "http_requests" metric. Every unique customer ID creates a wholly new series that the system must store, index, and keep in memory for queries. The cost drivers are both storage and compute: high cardinality cripples query performance because the engine has to sift through millions of series instead of hundreds, and it consumes enormous amounts of memory for indexing. Platforms meter it because their infrastructure strain scales directly with your cardinality, not just your data point volume.

Design habit: avoid high-cardinality tags like IDs as dimensions. Instead, keep them for logging, or use them in aggregated metrics (e.g., a histogram of request latency per customer, not a counter).


IntegrationWizard


   
ReplyQuote