ClickHouse vs Prometheus for High Cardinality, Part 2: Cardinality in ClickHouse

Summary

Traditional time-series databases like Prometheus experience write amplification, memory overhead, and operational challenges when high-cardinality label combinations churn rapidly. ClickHouse alters these economics by abandoning dedicated series objects in favor of a wide events model, storing telemetry as rows in columnar tables with dynamic Map attributes and metric measurements. Dynamic attributes can be handled using sharded Map types alongside materialized columns and text indexes for frequently queried labels. This design trades ingestion overhead for query-time processing, relying on columnar compression, partition pruning, and parallel scans to compute aggregations on demand. ClickHouse avoids the ingest-side bottlenecks of high cardinality, though Prometheus remains preferable for moderate cardinality, native PromQL semantics, and single-series lookups.

Takeaways

1. 1

   The Map type is recommended over JSON for ClickHouse observability data, with sharded maps mitigating historical read-time I/O overhead.

2. 2

   ClickHouse shifts high-cardinality costs from ingestion-time series creation to query-time scanning, pruning, and parallel aggregation.

3. 3

   Prometheus remains superior for mature PromQL semantics, complex range vectors, and targeted single-series lookups on moderate-cardinality data.