The number of unique label combinations a metric can produce, the cost driver and stability risk for time-series databases.
Metric cardinality is the count of unique label combinations a metric emits. A request-count metric labeled with method, status, route has cardinality method-count * status-count * route-count. Adding a label like user_id can blow that up by millions. High-cardinality labels are the leading cause of TSDB cost spikes, OOMs, and query slowdowns, because every unique combination is its own time series the database has to store, index, and query.
A single misconfigured metric with a high-cardinality label can balloon a Prometheus instance from gigabytes to terabytes in a day. Cardinality-aware design (label allowlists, hashing, sampling, or moving high-cardinality data to events instead of metrics) is the difference between an observability stack that scales and one that becomes the next outage.
See the part of the platform that handles cardinality (metric cardinality) in production.