Skip to content
Latchkey

ClickHouse vs Elasticsearch: Which for Logs/Analytics?

ClickHouse is a fast columnar database for analytics and log queries; Elasticsearch is a full-text search engine with strong text search and aggregations.

ClickHouse stores data columnar and compresses it aggressively, making large-scale analytical and log aggregation queries fast and cheap, though full-text search is less native. Elasticsearch indexes content for rich full-text search and faceted exploration, at higher storage cost. ClickHouse wins on analytical throughput and storage cost; Elasticsearch wins on full-text search and exploration UX.

ClickHouseElasticsearch
ModelColumnar SQLInverted index
StrengthAnalytics, aggregationsFull-text search
Storage costVery lowHigher
Full-textLimitedExcellent
Best forLog analytics at scaleSearch-heavy logs

Use case and cost

ClickHouse suits high-volume log and event analytics where SQL aggregations and storage cost dominate; many observability platforms now store logs in ClickHouse. Elasticsearch suits search-heavy use where users explore text freely and need ranking and facets.

Ops and CI fit

ClickHouse compresses extremely well and is efficient to run; Elasticsearch needs careful shard and heap tuning. Both are integration-tested in CI against ephemeral instances, where faster managed runners shorten image pulls and query tests.

Decide with your own numbers, not a feature table

Feature comparisons age badly and rarely decide anything, because both tools in a mature category can do the job. What differs is how each behaves on your repository, and that takes one afternoon to measure.

Terminal
# time a cold install with each candidate, cache cleared
hyperfine --prepare "rm -rf node_modules" --warmup 1 \
  "<tool-a> install" "<tool-b> install"

# and the thing CI actually pays for: a cold run with no local cache
docker run --rm -v "$(pwd):/w" -w /w node:22 sh -c "<tool> install"

What actually changes when you switch

  • Lockfile format. A switch is a one-way door for anyone still on the old tool until everyone migrates, so plan it as a single coordinated change.
  • Resolution strictness. Tools differ on whether an undeclared transitive import works, and the stricter one will surface latent bugs as new failures.
  • CI cache configuration. The cache path and key differ per tool; carrying over the old ones silently disables caching.
  • Everyone on the team and every runner must move together. Pin the version so they cannot drift.

The verdict

Want cheap, fast log analytics with SQL: ClickHouse. Want rich full-text search and exploration: Elasticsearch. Analytics and cost favor ClickHouse; search depth favors Elasticsearch.

Frequently asked questions

ClickHouse vs Elasticsearch: Which for Logs/Analytics?
ClickHouse stores data columnar and compresses it aggressively, making large-scale analytical and log aggregation queries fast and cheap, though full-text search is less native. Elasticsearch indexes content for rich full-text search and faceted exploration, at higher storage cost.
Use case and cost?
ClickHouse suits high-volume log and event analytics where SQL aggregations and storage cost dominate; many observability platforms now store logs in ClickHouse. Elasticsearch suits search-heavy use where users explore text freely and need ranking and facets.
Ops and CI fit?
ClickHouse compresses extremely well and is efficient to run; Elasticsearch needs careful shard and heap tuning. Both are integration-tested in CI against ephemeral instances, where faster managed runners shorten image pulls and query tests.
Which should I choose?
Want cheap, fast log analytics with SQL: ClickHouse. Want rich full-text search and exploration: Elasticsearch. Analytics and cost favor ClickHouse; search depth favors Elasticsearch.

Related guides

References

Run this faster and cheaper on Latchkey managed runners - self-healing included. Start free → 30-day trial · No credit card