Last9
Read post

High Cardinality in ClickHouse at Scale: What Actually Breaks

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.

    #observability#clickhouse
Jun 25•13m read time•From 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
446 Impressions
Last9's image
Last9

Last9 is a blog focusing on DevOps practices, cloud architecture, and software engineering methodol...

197 Followers

•

4.3K Upvotes

Would you recommend this post?

Copy link
WhatsApp
Facebook
X
New Squad
  • © 2026 Daily Dev Ltd.
  • Guidelines
  • Explore
  • Tags
  • Sources
  • Squads
  • Leaderboard