That observation is the reason this comparison comes up so often. ClickHouse is an analytical database, Elasticsearch is a search engine, and the two overlap heavily in log analytics and observability. This guide compares them honestly: how each one is built, where each genuinely wins, what the cost and performance claims really amount to, and when it makes sense to run both. If you want the ClickHouse background first, our ClickHouse tutorial for beginners and ClickHouse architecture deep dive cover it in detail.

ClickHouse vs Elasticsearch at a Glance

Two Engines, Two Data Structures

Almost every difference in this comparison traces back to one choice: what data structure sits at the center of each system.

Elasticsearch: The Inverted Index

(cite index=”129-1″>Elasticsearch is a distributed search engine built on Apache Lucene, where an index is split into shards, each of which is a complete Lucene index that can have replicas. The star of Lucene is the inverted index. (cite index=”131-1″>When Lucene analyzes a field, it builds a mapping from each term to the list of document IDs containing that term, called a postings list. Search for “timeout” and Elasticsearch jumps straight to the documents containing it without scanning anything else.

That structure is magnificent for search and a poor fit for arithmetic over many documents. (cite index=”131-1″>For sorting, aggregations, and numeric range queries, Elasticsearch uses doc values instead, a column-oriented store mapping document IDs to field values. So Elasticsearch already contains a columnar store, but it lives alongside the inverted index and the original source document rather than replacing them.

Data lands in immutable pieces here too. (cite index=”125-1″>Lucene writes data in segments, and Elasticsearch periodically refreshes indices, by default every second, making new documents searchable in near real time rather than instantly. That one-second visibility is a real strength for interactive log exploration.

ClickHouse: Columns All the Way Down

ClickHouse starts from the opposite end. Data is stored as compressed columns inside immutable sorted parts, with a sparse index that skips irrelevant granules, as covered in our architecture guide. There is no per-document inverted index by default, no stored copy of the original JSON blob, and no analysis step at write time.

The consequence is a clean split of strengths. Elasticsearch pays extra at write time and in storage to make “find the documents matching this text” instant. ClickHouse pays nothing extra and makes “scan these columns and aggregate” instant.

Query Language and Developer Experience

(cite index=”115-1″>ClickHouse speaks SQL, while Elasticsearch offers its own Query DSL alongside EQL and a SQL interface. For teams that already think in SQL, or that want to join logs against other tables and feed BI tools, ClickHouse feels natural immediately. Elasticsearch’s JSON-based Query DSL is powerful and expressive for search, but it has a steeper learning curve for analytical questions that SQL handles in one line.

Schema handling differs in the same spirit. (cite index=”115-1″>Elasticsearch is schema-dynamic, while ClickHouse is strict. Dynamic mapping lets you throw unpredictable JSON at Elasticsearch and search it immediately, which is a real advantage when document structure keeps changing. ClickHouse asks you to declare columns and types up front, which takes effort but catches bad data early and keeps storage and queries fast.

Full-Text Search: Elasticsearch’s Home Turf

This is where Elasticsearch earns its reputation, and it deserves an honest look.

(cite index=”116-1″>Elasticsearch offers relevance ranking, analyzers, and fuzzy matching. (cite index=”133-1″>Its feature set includes BM25 scoring, synonyms, and fuzzy search, which together let you return the best matches first, tolerate typos, and understand language rather than just match strings. If search quality is a product feature, say an e-commerce catalog or documentation search, this is exactly what you want.

ClickHouse has been narrowing the gap, but the gap is real. (cite index=”118-1″>ClickHouse now handles searching billions of logs for a specific error message while computing average latency or error rate in the same query, but relevance ranking with BM25 is not supported. (cite index=”119-1″>A text index in ClickHouse can make keyword search around 7.4 times faster than a plain scan, yet Elasticsearch still leads for fuzzy free-text search.

Reported speed gaps on keyword search vary by benchmark, and you should treat any single number with caution. (cite index=”120-1″>One comparison puts Elasticsearch at roughly 3 to 10 times faster than ClickHouse’s token-based search for full-text keyword queries, while (cite index=”122-1″>another shows ClickHouse’s search taking 2 to 5 seconds against Elasticsearch’s 0.5 to 1 second. The pattern is consistent even when the magnitude isn’t: Elasticsearch wins keyword and relevance search, and ClickHouse is good enough for many log-search needs.

One nuance favors ClickHouse. (cite index=”119-1″>Searching on object storage degrades in Elasticsearch, which wants fast local SSDs, while ClickHouse runs at full speed against S3. For long-retention logs, that matters.

Aggregations and Log Analytics: ClickHouse’s Home Turf

Flip the workload to “count, group, and percentile over huge volumes” and the picture reverses.

Most log queries are not searches at all. They’re questions like how many 500 errors per service in the last hour, or what the p99 latency is by endpoint. (cite index=”119-1″>For those aggregation-style queries, one benchmark of OTEL logs at 1 billion to 50 billion rows found ClickHouse 2 to 6 times faster on cold queries and 1.7 to 2.6 times faster on hot ones. Other comparisons claim much larger gaps, with (cite index=”120-1″>one citing 10 to 100 times faster aggregation and (cite index=”122-1″>another listing a count over 1 billion rows at 0.5 seconds versus 3 to 5 seconds.

Why such a wide spread? Because results depend heavily on data shape, hardware, index settings, and how carefully each side was tuned, and many published numbers come from vendors or ecosystem blogs with a stake in the answer. A safe reading is that ClickHouse is consistently faster for structured aggregations, by a factor somewhere between a couple of times and an order of magnitude. The only number that matters for you is the one from your own data.

The architecture explains the direction of the gap. (cite index=”116-1″>Elasticsearch, used as a log store, carries the cost of inverted indexes, per-document analysis, and multiple stored representations of the same data that the workload never exercises. ClickHouse reads only the columns a query needs and skips the rest.

Storage and Compression

Here the claimed gap is large and fairly consistent across sources. (cite index=”121-1″>ClickHouse, with its columnar layout and ZSTD compression, commonly compresses log data 5 to 10 times, and (cite index=”119-1″>one migration write-up reports a footprint more than 5 times smaller than Elasticsearch. (cite index=”115-1″>A more optimistic comparison lists 10 to 30 times compression for ClickHouse against 1.5 to 3 times for Elasticsearch.

The reasons are structural. Elasticsearch stores the original document, the inverted index, and the doc values, so the same information exists in several forms. ClickHouse stores each column once, compressed with type-aware codecs like DoubleDelta for timestamps, as we covered in the architecture article.

Compression is not the whole cost story, though, because Elasticsearch’s extra structures are exactly what make its search fast. You’re paying for a capability. The question is whether you use it.

Cost: What the Numbers Suggest

Cost comparisons are where claims get loudest, so a measured reading helps.

Published estimates for roughly 100 TB of raw logs per month point the same way. (cite index=”122-1″>One lists ClickHouse storage at about $200 per month against about $1,000 for Elasticsearch, and concludes ClickHouse costs 60 to 70 percent less for log analytics. (cite index=”115-1″>Another estimates compute at about $2,000 per month for ClickHouse versus $6,000 for Elasticsearch, a 3 to 5 times total cost advantage.

There’s at least one real-world data point. (cite index=”120-1″>Canva, which migrated from OpenSearch, an Elasticsearch fork, to ClickHouse, reported 70 percent lower costs and 10 times faster search performance, according to ClickHouse’s own case study. Note the source, though: a vendor case study, and OpenSearch rather than Elasticsearch proper.

Treat these as directional. Your real costs depend on retention, replication factors, hardware, whether you use object storage tiers, and the engineering time spent running each system. (cite index=”116-1″>A fair evaluation models compute, storage, and the operational effort of running another system. If you only have modest log volume, the savings may not justify a migration at all.

Ingestion and Freshness

Freshness is a place where Elasticsearch has a real edge. Documents are searchable within about a second of indexing, and you can index one document at a time without drama.

ClickHouse wants the opposite. As our tutorial stressed, small frequent inserts create too many parts, so production pipelines batch rows or use asynchronous inserts. Data becomes queryable as soon as an insert completes, but you design around batches rather than single events. For streaming logs this is usually handled by a collector or buffer, and it’s rarely a blocker, but it is a different mental model.

Scaling rules differ as well. (cite index=”126-1″>In Elasticsearch the number of primary shards is fixed when an index is created and can’t be changed afterward, so capacity planning means picking shard counts and sizes carefully up front. (cite index=”129-1″>A common rule of thumb is to keep shards in the 10 to 50 GB range. ClickHouse has its own tuning concerns, such as partition keys and merge pressure, but not that exact constraint.

Licensing and Openness

Licensing is a genuine differentiator, and the history is messy enough to spell out.

(cite index=”132-1″>Elasticsearch moved from Apache 2.0 to a dual SSPL and Elastic License 2.0 model in January 2021 with the 7.11 release, restricting its use as a managed service, which led Amazon to fork it as OpenSearch. (cite index=”132-1″>Since late 2024, Elasticsearch source is also available under AGPLv3, an OSI-approved license, in addition to SSPL and Elastic License 2.0. (cite index=”132-1″>OpenSearch remains an Apache 2.0 fork of Elasticsearch 7.10.2.

ClickHouse is licensed under Apache 2.0, a permissive open-source license. If your organization requires a permissive license with no copyleft considerations, that is a straightforward point in ClickHouse’s favor, and OpenSearch is the Elasticsearch-family option that offers the same.

Ecosystem and Tooling

Elasticsearch brings a mature ecosystem, and for many teams that’s the deciding factor. (cite index=”116-1″>Teams that depend on Kibana and the wider Elastic Stack have a strong reason to stay. Kibana’s discover view, saved searches, and alerting are polished and familiar.

ClickHouse is assembling a comparable story for observability through ClickStack, which pairs it with log, trace, and metric tooling. It also connects naturally to BI tools via SQL and to the lakehouse world, as discussed in our Apache Iceberg tutorial. The trade is simple: Elasticsearch has the more established search-and-explore experience, while ClickHouse offers SQL and cost efficiency.

Operations and Scaling

Running either system at scale is real work, and the shape of that work differs.

Elasticsearch clusters revolve around shards, replicas, and node roles. You size shards, decide how indices roll over, and manage the lifecycle of time-based indices as they age. Because primary shard counts are fixed at creation, mistakes tend to be fixed by reindexing, which is expensive on large datasets. The upside is a mature set of operational patterns that many engineers already know.

ClickHouse operations center on different levers: choosing the sorting and partition keys, keeping insert batches healthy so merges keep up, and, for clusters, running replication through ClickHouse Keeper and deciding how to shard. These are also unforgiving if chosen badly, since a poor sorting key means scanning far more data than necessary, but the concepts are fewer and mostly decided at table-design time. Our architecture guide walks through each of those levers in detail.

Storage tiering deserves a mention because retention drives cost. (cite index=”119-1″>ClickHouse can run at full speed against object storage, while Elasticsearch degrades without fast SSDs, which makes it easier to keep months or years of logs on inexpensive storage while still querying them interactively. For teams with compliance-driven retention, that single difference can reshape the budget.

Thinking About a Migration

If you’re considering moving logs from Elasticsearch to ClickHouse, a few lessons from published migration stories are worth borrowing.

First, inventory your queries before you move anything. Sort them into search-style queries (find this text), aggregate-style queries (count, group, percentile), and exploratory ones. (cite index=”119-1″>One migration write-up notes that most log queries are aggregations like error counts, latency percentiles, and service health, where ClickHouse has the advantage. If your inventory looks like that, you’re a good candidate. If it’s mostly text search, think twice.

Second, plan to rebuild the exploration experience. Kibana’s Discover view is familiar, and replacing it means choosing a ClickHouse-friendly front end and teaching people a SQL-first workflow. That’s a people cost as well as a technical one.

Third, run both in parallel for a while. Dual-writing new data lets you compare answers, validate dashboards, and build confidence before you cut over, and it keeps a safety net in place if a workload turns out to need Elasticsearch after all.

Finally, model the whole picture. Compression and compute savings are real, but so are the costs of migration effort, retraining, and running a second system during the transition.

Using Both Together

This isn’t always an either/or decision. (cite index=”115-1″>Many organizations migrate log storage to ClickHouse while keeping Elasticsearch for search-specific use cases, getting cost savings without losing search capability. A common pattern is to send high-volume telemetry to ClickHouse for long retention and aggregation, while a smaller, curated set of documents stays in Elasticsearch to power relevance-ranked search.

If part of your workload is relevance-ranked text search, keep Elasticsearch for that part. (cite index=”116-1″>Choose Elasticsearch when relevance-ranked search is a product feature, when you need fast single-document retrieval, when you depend on Kibana, when document structure is unpredictable, or when log volume is modest enough that storage cost isn’t a concern.

When to Choose ClickHouse

ClickHouse tends to be the stronger choice when:

• Your workload is logs, metrics, traces, or events where most queries filter and aggregate.
• Storage cost and long retention are real pain points.
• You want SQL, joins to other tables, and easy BI integration.
• Your data has a reasonably stable structure.
• You want a permissively licensed engine that runs well against object storage.

When to Choose Elasticsearch

Elasticsearch tends to be the stronger choice when:

• Relevance-ranked, typo-tolerant full-text search is a core product feature.
• You need fast single-document lookups and retrieval.
• Your documents have unpredictable, evolving structure.
• Your team already depends on Kibana and the Elastic Stack.
• Data volumes are modest enough that cost isn’t a concern.

Frequently Asked Questions

Is ClickHouse faster than Elasticsearch? For structured aggregations over large volumes, usually yes, with published comparisons ranging from a couple of times faster to an order of magnitude. For full-text keyword and relevance search, Elasticsearch is usually faster. Benchmark with your own data before deciding.

Can ClickHouse replace Elasticsearch? For log analytics and observability, often yes, and many teams have done it to cut cost. For relevance-ranked search with BM25, fuzzy matching, and analyzers, it can’t fully replace Elasticsearch, so many teams keep both.

Does ClickHouse support full-text search? Yes, in a more basic form. It offers token-based search, ngram indexes, and a text index, but it doesn’t provide BM25 relevance scoring.

Why does Elasticsearch use more storage? It stores the original document, an inverted index, and columnar doc values, so the same data exists in multiple forms. ClickHouse stores each column once with strong compression.

Is Elasticsearch open source? It’s source-available under SSPL and Elastic License 2.0, and since late 2024 also available under the OSI-approved AGPLv3. OpenSearch, Amazon’s fork of an earlier version, is Apache 2.0.

Is ClickHouse open source? Yes, it’s licensed under Apache 2.0.

Is Elasticsearch real time? Near real time. Documents become searchable within about one second, based on the default refresh interval, but not instantly.

Which one should I use for logs? If your queries are mostly filtering and aggregating, ClickHouse is usually the more economical and faster choice. If you rely heavily on text search and Kibana, Elasticsearch may fit better, and you can combine them.

Final Verdict

The honest answer is that these tools were built for different jobs and happen to meet in the middle. Elasticsearch is a search engine that learned to do analytics, and ClickHouse is an analytics engine that learned to do search. If relevance-ranked text search is what you sell, Elasticsearch remains the right foundation. If you’re storing mountains of structured telemetry and mostly asking aggregate questions, ClickHouse will usually be faster and considerably cheaper.

Before you migrate anything, test both on a representative slice of your own data, model the full cost including operations, and consider the hybrid pattern. For authoritative detail, ClickHouse’s documentation and Elastic’s documentation are the best places to go deeper.

For more breakdowns of open-source data infrastructure and analytics tooling like this one, keep exploring the guides on CourseDrill.