So, is ClickHouse winning the observability wars?

Summary

The article examines whether ClickHouse is “winning” observability by separating the storage-and-query question from the broader work of collection, schema design, correlation, visualization, alerting, and investigation. It argues that ClickHouse fits telemetry because its columnar layout stores fields separately, enabling compression and allowing analytical queries to read only selected columns across millions or billions of events; ordering keys, sparse primary indexes, and data-skipping indexes further reduce work. The discussion covers both rich, wide events and conventional logs, traces, and metrics, and presents ClickStack as a combination of ClickHouse, an OpenTelemetry Collector, and a UI that preserves familiar workflows. The conclusion is qualified: ClickHouse has become the de facto storage and query engine for many teams and a strong default for large telemetry workloads, but it has not won observability as a whole, while full-text indexes, PromQL support, and broader product layers remain important.

Takeaways

1. 1

   ClickHouse’s columnar layout suits observability queries that scan selected fields across millions or billions of events, while compression can reduce storage substantially.

2. 2

   Teams can use ClickHouse with rich wide events or with existing logs, traces, and metrics; ClickStack is presented as supporting both models without requiring telemetry to be remodelled.

3. 3

   The article concludes that ClickHouse is a strong default storage and query engine, but that no single database wins observability because product and workflow layers remain essential.