DATABASES Signal 507
So, is ClickHouse winning the observability wars?
↗
ClickHouse responds to claims that it is winning the observability wars, arguing that while it has become the default storage and query engine for telemetry, that does not mean it has won the broader observability product space.
For engineers building observability systems, ClickHouse's columnar architecture makes it a strong choice for storing and querying logs and traces at scale, as evidenced by its use at Netflix, Anthropic, and OpenAI. However, the article cautions that a good storage engine cannot compensate for poor architecture or product decisions, so teams should not assume that adopting ClickHouse alone solves observability.
Written by elseif from the cluster below · every claim links back to a sourceThe three things worth knowing
ClickHouse has become the default storage and query engine for many teams building observability systems, including at Netflix, Anthropic, and OpenAI.
The article argues that winning the storage layer is not the same as winning observability, as collection, schema design, correlation, visualization, and alerting still need to be built.
ClickHouse works with both wide events and conventional logs and traces, and products like ClickStack combine it with an OpenTelemetry Collector and UI.
THE READ
What the cluster adds up to.
The article is ClickHouse's own response to public claims by Mat Duggan and Charity Majors that it is winning the observability wars. It acknowledges that at the storage and query layer, ClickHouse has become a default choice for teams building observability systems, citing its use at Netflix, Anthropic, and OpenAI. The change is that ClickHouse is publicly reflecting on its role and the limits of that role.
Adopting ClickHouse for observability means embracing a columnar database that suits high-cardinality, wide structured data. The article notes that it works with both wide events and conventional logs and traces, so teams do not have to remodel their telemetry. However, the cost is that ClickHouse only addresses the storage and query layer; teams still need to build collection, schema design, correlation, visualization, alerting, and investigation workflows.
The article explicitly says that a better storage engine cannot beat bad architecture, quoting Charity Majors. This is where ClickHouse stops being the answer: if the overall observability system is poorly designed, the engine will not fix it. The article also suggests that winning the database layer is not the same as winning observability, because the product decisions and user experience are separate.
The article also highlights that many observability SaaS companies build products on top of ClickHouse, owning the interface and workflows. This indicates that ClickHouse is a component, not a complete solution. The article ends with a call to action for ClickStack Cloud, a turnkey platform, which shows that ClickHouse is moving up the stack to address the missing layers.
Written by elseif from the cluster below · checked for specifics the sources never containedTHE CLUSTER