What is the difference between ClickHouse and Elasticsearch for log analytics?

Think of two different types of librarians. One librarian (Elasticsearch) has memorized every word in every book and can instantly find which books contain any phrase you ask about. The other librarian (ClickHouse) has organized books into precise categories with detailed statistics and can instantly tell you how many books were published per year, the average page count by genre, or trends over time. You pick the librarian based on whether you need to find specific text or analyze patterns in structured data.

ClickHouse and Elasticsearch approach log analytics from fundamentally different architectures. Elasticsearch uses an inverted index that maps every term to the documents containing it, enabling millisecond full-text search across unstructured text. ClickHouse uses columnar storage with sparse indexes optimized for scanning and aggregating structured fields like timestamps, status codes, service names, and numeric metrics. Both can handle log analytics, but they trade off differently.

Internally, the storage efficiency difference is dramatic. Elasticsearch stores the original document plus an inverted index for every field, plus doc values for aggregations, resulting in significant storage amplification (often 1.5-3x the raw data size). ClickHouse stores only the columnar data with compression, typically achieving 5-20x compression on structured log fields. A 10TB/day log pipeline might require 30TB of Elasticsearch storage versus 2-5TB in ClickHouse. This translates directly to infrastructure cost savings of 3-10x.

At production scale, the query performance difference depends on the workload. For aggregations (count errors per service per hour, p99 latency by endpoint, unique users by country), ClickHouse is 5-50x faster because it scans compressed columns without index overhead. For full-text search (find all logs containing a specific error message substring), Elasticsearch is dramatically faster because ClickHouse must scan the entire string column while Elasticsearch jumps directly to matching documents via the inverted index. Many organizations use both: ClickHouse for dashboards and analytics, Elasticsearch for ad-hoc text search.

The non-obvious gotcha is that ClickHouse has added full-text index support (tokenbf_v1, ngrambf_v1 bloom filter indexes) that narrows the gap for log search use cases. These are not as capable as Elasticsearch's inverted index, but for structured log analytics where 90% of queries filter on known fields and only occasionally search message text, ClickHouse can serve both needs. Teams should evaluate whether their actual query patterns justify the cost and complexity of maintaining two systems.