ClickHouse handles high-cardinality observability data fundamentally differently from Prometheus by using a 'wide events' model instead of series-based storage. Rather than creating separate time series per label combination, ClickHouse stores timestamped rows with dynamic label maps and numeric metric columns. Key techniques include sharded Map types for dynamic labels, materialized columns for frequently queried dimensions, sparse primary indexes, inverted text indexes over map keys/values, and columnar compression. Cardinality costs shift from ingestion time (as in Prometheus) to query-time aggregation, where large GROUP BY operations on high-cardinality columns require memory and can be managed via disk spilling. The post also clarifies where Prometheus still wins: targeted single-series lookups, PromQL-native alerting, and moderate-cardinality traditional monitoring workflows.
Table of contents
Why cardinality is different in ClickHouse #When high cardinality still has a cost in ClickHouse #When ClickHouse makes sense #When Prometheus still makes sense #Conclusion #Sort: