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.