Elasticsearch was the default for log analytics for a decade, but at scale its storage and cost overhead pushed many teams to look elsewhere — and ClickHouse has become the leading answer. The two take fundamentally different approaches: an inverted index built for full-text search versus a columnar engine built for analytics. This guide compares them for logs.
Two different engines
Elasticsearch is built around an inverted index — excellent for full-text relevance search, where you want the best-matching documents for a term. ClickHouse is a columnar (OLAP) database — built to scan and aggregate huge volumes of data fast. Logs are mostly an analytics workload (filter, aggregate, group, trend over time), which is exactly what a columnar engine is good at.
Storage and compression
This is where the gap is widest. Elasticsearch physically stores each document multiple times — in the inverted index for search, in stored fields for retrieval, and in doc-values for aggregations — and typically achieves only modest compression. ClickHouse, with columnar layout and ZSTD compression, commonly compresses log data 5–10×.
| Elasticsearch | ClickHouse | |
|---|---|---|
| Storage model | Inverted index + stored fields + doc-values | Columnar with per-column compression |
| Typical compression | ~1.5:1 | ~5–10:1 (ZSTD) |
| Relative disk for same data | ~12–19× more | Baseline |
| Aggregation query speed | Slower at scale | Typically 10–50× faster |
Cost
Storage efficiency and CPU usage drive cost. Elasticsearch's index-building and JVM overhead make both storage and compute expensive at scale, so the same retention needs far more nodes than ClickHouse. For high-volume log workloads, the difference is routinely an order of magnitude — which is why log-retention conversations and cost reviews so often end up at ClickHouse. See log retention requirements for the retention side of that trade-off.
Where Elasticsearch still wins
This is not one-sided. Elasticsearch is genuinely strong where you need full-text relevance ranking — search-engine use cases, complex text scoring, and rich text-analysis features. If your workload is document search rather than log analytics, the inverted index is the right tool. For logs — high-volume, time-series, filter-and-aggregate — the analytics engine usually wins.
Match the engine to the workload
Logs are an analytics problem far more than a relevance-search problem. That is why purpose-built log platforms increasingly run on columnar engines rather than inverted indexes.
How LogPulse uses ClickHouse
LogPulse is built on ClickHouse, which is what makes sub-200ms search across billions of events and long, affordable retention possible — without you operating the database. A familiar pipe-based query language (LPQL) and natural-language AI search sit on top, so you never hand-write SQL. See log management on ClickHouse and what is log management.