ClickHouse vs Prometheus for High Cardinality, Part 1: Understanding the Problem

High cardinality is a well-known pain point in Prometheus and similar series-oriented time-series databases. This post explains why: every unique label combination creates an independent time series, each carrying its own in-memory structure (memSeries), inverted index entries, and chunk overhead. As cardinality grows — especially with ephemeral labels like container_id or pod_id in Kubernetes — memory consumption scales linearly, ingestion slows due to repeated series creation, and broad queries become expensive because Prometheus must decode full chunks across many posting lists. Teams typically respond by stripping labels, increasing scrape intervals, or capping series counts, all of which reduce observability fidelity. The post sets up a follow-on piece explaining how ClickHouse's columnar storage model handles these same workloads differently.