ClickHouse vs Elasticsearch for Log Storage: Cost, Speed, and Trade-offs

Every log management system stores logs somewhere. The two most common choices are Elasticsearch (the "E" in ELK) and ClickHouse. They solve the same problem — store and query large volumes of timestamped data — but they approach it from opposite directions.

Elasticsearch is a full-text search engine adapted for log storage. ClickHouse is a columnar analytics database adapted for log queries. The difference matters more than most teams realize until they're paying the storage bill.

Architecture: Why They're Different

Elasticsearch

Elasticsearch stores data in inverted indexes — the same data structure that powers Google. Every word in every log message is indexed, making arbitrary text search ("find all logs containing NullPointerException") very fast.

The cost: every field is indexed by default. A single log entry is stored in the original _source document and in the inverted index for every field. For structured logs with 15-20 fields, the storage overhead is 2-4x the raw data size.

ClickHouse

ClickHouse stores data in columns. All values for a single column (e.g., all level values, all timestamp values) are stored together, then compressed. Since log data within a column is highly repetitive ("info", "info", "info", "error", "info"...), compression ratios of 10-20x are common.

The cost: ClickHouse doesn't build inverted indexes. Full-text search on arbitrary strings requires scanning column data, which is slower than Elasticsearch's index lookup for rare terms. However, for structured fields (level, service, status code), columnar storage is significantly faster.

Storage Efficiency

This is where the difference is most dramatic. For the same 100 GB of raw log data:

Metric	Elasticsearch	ClickHouse
Storage on disk	130-250 GB	15-40 GB
Compression ratio	0.7-1.5x (with replicas: 2-3x raw)	5-15x
RAM required	32+ GB (JVM heap + OS cache)	4-8 GB
Recommended CPU	8+ cores	4+ cores

Elasticsearch's inverted indexes and the JVM's memory requirements make it significantly more expensive to run at scale. A setup that handles 100 GB/day on Elasticsearch typically needs 3-5 nodes with 64 GB RAM each. The same volume on ClickHouse runs comfortably on a single 16 GB node.

For self-hosted deployments, this translates directly to server costs:

Volume	Elasticsearch monthly server cost	ClickHouse monthly server cost
10 GB/day	~$150-300 (3 nodes)	~$30-60 (1 node)
100 GB/day	~$800-1,500 (5+ nodes)	~$100-250 (1-2 nodes)
1 TB/day	~$5,000-10,000 (cluster)	~$500-1,500 (3-4 nodes)

These are rough estimates for cloud VMs with SSD storage. Actual costs depend on retention, query load, and replication factor.

Query Performance

Aggregate queries (ClickHouse wins)

The most common log queries are aggregations: error count per service, error rate over time, top 10 error messages, p99 latency by endpoint. These are exactly what columnar databases are designed for.

-- "Error count per service in the last hour"
-- ClickHouse: 50-200ms on 1 billion rows
-- Elasticsearch: 500-3,000ms on the same data
SELECT service, count(*)
FROM logs
WHERE level = 'error' AND timestamp > now() - INTERVAL 1 HOUR
GROUP BY service
ORDER BY count(*) DESC

ClickHouse scans only the level, timestamp, and service columns — ignoring the message, attributes, and every other field. Elasticsearch reads more data because its storage layout is row-oriented (each document stores all fields together).

Benchmark comparisons consistently show ClickHouse running aggregate queries 3-8x faster than Elasticsearch on equivalent hardware.

Full-text search (Elasticsearch wins)

"Find all logs containing 'Connection reset by peer' in the last 24 hours"

This is where Elasticsearch's inverted index shines. The search term is looked up in the index, and matching document IDs are returned without scanning the data. For rare terms in large datasets, Elasticsearch can be 10-100x faster.

ClickHouse handles this with LIKE or hasToken() functions, which scan the message column. With good compression, this is fast enough for most use cases (sub-second on tens of millions of rows), but it doesn't match Elasticsearch's index lookup speed for rare strings.

However: most log searches in practice are not full-text searches. They're structured field filters: level = 'error', service = 'api', status_code = 500. For these, ClickHouse is faster.

Point lookups (roughly equal)

"Find the log entry with trace_id = 'abc123'"

Both handle this well. Elasticsearch uses the inverted index. ClickHouse uses primary key indexing (if the table is ordered by the right columns) or column scanning with early termination.

Operational Complexity

Elasticsearch

Running Elasticsearch in production requires:

• JVM tuning — heap size, garbage collection settings, circuit breakers
• Cluster management — master nodes, data nodes, coordinating nodes, shard allocation
• Index lifecycle management — rollover, shrink, freeze, delete policies
• Shard planning — too many shards degrades performance, too few limits parallelism
• Recovery procedures — shard relocation after node failure can take hours on large clusters
• Version upgrades — rolling upgrades across cluster nodes, breaking API changes between major versions

The learning curve is steep. Most teams underestimate the ops effort until they've been running it for 6 months.

ClickHouse

ClickHouse operational requirements:

• Table engine selection — MergeTree family, partition key, order key
• TTL for retention — ALTER TABLE logs MODIFY TTL timestamp + INTERVAL 30 DAY
• Merges — background process that compacts data parts (mostly automatic)
• Replication — via ClickHouse Keeper or ZooKeeper (if high availability is needed)

ClickHouse is operationally simpler for single-node deployments, which handle surprisingly large volumes. The complexity increases with replication and sharding, but most log management workloads don't need multi-node clusters until 500+ GB/day.

When to Use Each

Choose Elasticsearch when:

• Full-text search is the primary use case — searching arbitrary strings in unstructured log messages, not structured fields
• The ELK ecosystem is already in place — Kibana dashboards, Logstash pipelines, Beats agents are deployed and maintained by a dedicated team
• Complex text analysis is needed — fuzzy matching, relevance scoring, multi-language tokenization
• The team has Elasticsearch expertise — operational knowledge is already on the team

Choose ClickHouse when:

• Cost efficiency matters — 5-10x less storage, lower hardware requirements
• Aggregate queries dominate — error rates, counts, percentiles, time series charts
• High ingest rates are expected — ClickHouse handles 500K+ rows/second on modest hardware
• Structured logs are the norm — JSON with consistent field names, not free-form text
• Operational simplicity is valued — single node handles most workloads, simpler configuration

The hybrid approach

Some log platforms use both: ClickHouse for storage and aggregate queries, with a lightweight search index for full-text lookups. This gets the storage efficiency of ClickHouse with acceptable text search performance.

LogFlow, for example, stores all log data in ClickHouse and supports structured field search (level:error AND service:api) natively. For most debugging workflows — filtering by level, service, time range, and keywords — columnar storage is fast enough without a separate search index.

The Bottom Line

For a team evaluating log storage in 2026:

• Elasticsearch is the battle-tested default with the largest ecosystem, but it's expensive to run and complex to operate at scale.
• ClickHouse is the cost-efficient alternative that handles 90% of log query patterns faster and cheaper, with a trade-off on full-text search speed for rare terms.

The industry trend is moving toward ClickHouse. Grafana Loki, Signoz, Highlight, and several other observability platforms have adopted ClickHouse as their primary storage engine over the past two years. Elasticsearch remains dominant in legacy deployments and use cases where full-text search is non-negotiable.

For most applications — structured JSON logs with field-based search and time-range queries — ClickHouse is the better fit on both performance and cost.

---

The storage engine is an implementation detail that most teams shouldn't manage themselves. Whichever engine powers the backend, the important thing is that logs are searchable, alerts are firing, and nobody is SSH-ing into servers at 3am to grep through files.