Running ClickHouse at scale with high-cardinality telemetry data reveals a deceptive failure pattern: ingest stays healthy while query-time costs accumulate silently. Three distinct failure modes emerge at scale — memory exhaustion during GROUP BY aggregations, part explosion from fine-grained grouping keys in materialized views, and full-text scans on unindexed high-cardinality columns. Real production numbers are shared, including a spike to 400M rows/minute that caused 160 concurrent merges and 40-50 second insert latencies. Mitigations include designing ORDER BY keys around real query patterns, adding tokenbf_v1 bloom filters for high-cardinality text lookups, coarsening timestamp granularity in materialized views, promoting hot Map keys to typed LowCardinality columns, and avoiding SELECT * on wide tables.

13m read timeFrom last9.io
Post cover image
Table of contents
The failure timelineWhy cardinality bites ClickHouse at query timeWhat it looks like under real loadThe mitigations we actually useWhat we would tell someone starting todayFAQ
458 Impressions