ClickHouse vs Elasticsearch for Logs: Architecture, Performance & Cost Compared (2026)

For years, the choice between ClickHouse and Elasticsearch for log storage was straightforward. Elasticsearch handled full-text search. ClickHouse handled analytics. Teams either picked one or ran both.

That division no longer holds as cleanly as it once did. ClickHouse added redesigned full-text search powered by inverted indexes, reaching general availability in version 26.2 in March 2026, and published a self-run benchmark showing ClickHouse completing the full-text analytical log workload 2 to 6 times faster than Elasticsearch across datasets up to 50 billion rows. Meanwhile, Elasticsearch has continued closing the storage efficiency gap through its logsdb index mode, now showing up to 77% storage reduction in Enterprise mode benchmarks.

The ClickHouse vs Elasticsearch for logs question is now more nuanced than it was two years ago. Both tools can do full-text search. Both tools handle structured log analytics. But they are built around fundamentally different data structures, and those differences still determine which one is the right fit for your workload, team, and budget.

This article draws only from ClickHouse‘s official documentation and benchmarks and Elastic’s official documentation and product pages.

Architecture: columnar vs inverted index

This is the most important dimension to understand before comparing any other feature.

ClickHouse: Columnar analytical engine

ClickHouse stores data by column, not by row. When a query reads only five fields from a 100-field log schema, ClickHouse reads only those five columns from disk. This makes aggregations (GROUP BY, COUNT, SUM, percentiles) across billions of events extremely fast and storage-efficient, because unneeded columns are never touched.

ClickHouse’s vectorized execution engine processes data in batches using SIMD instructions. Combined with ZSTD compression at the column level, this delivers both high ingest throughput and fast analytical queries at scale. ClickHouse handles observability data as wide events, meaning all log fields including high-cardinality attributes like user IDs, request IDs, and trace IDs are stored natively without the field count limitations that affect Elasticsearch at high cardinality.

As documented on clickhouse.com’s observability page, teams migrating from Elasticsearch to ClickStack have seen storage cost reductions of more than 50% for the same log data.

Elasticsearch: Inverted index search engine

Elasticsearch is built on Apache Lucene. Its primary data structure is the inverted index: a structure that maps each unique term to every document containing it. As documented, the inverted index is what makes Elasticsearch’s full-text search fast. When you search for a term, Elasticsearch looks it up directly in the index rather than scanning every document.

Elasticsearch uses BM25 (Best Match 25) as its default relevance scoring algorithm, which ranks results by term frequency in the document versus rarity across the full index. This relevance ranking is something ClickHouse does not provide. ClickHouse returns rows matching a filter condition but does not score them by textual relevance.

Elasticsearch stores each document as JSON. Historically, it stored the original JSON blob alongside the inverted index, the BKD tree for numeric data, and doc values for aggregations. This multi-structure storage model has been the source of Elasticsearch’s historically higher storage footprint compared to columnar databases for the same log data, though logsdb index mode has substantially addressed this.

Full-text search

ClickHouse: ClickHouse’s redesigned full-text search, implemented as a text index (inverted index), reached general availability in ClickHouse version 26.2 in March 2026, as documented in the official ClickHouse text indexes documentation and the GA announcement. The ClickHouse docs explicitly state: “Text indexes are generally available (GA) in ClickHouse version 26.2 and newer. We strongly recommend using ClickHouse versions >= 26.2 for production use cases.”

The key architectural distinction, as explained in ClickHouse’s April 2026 benchmark post, is that matching documents from the inverted index are fed directly into ClickHouse’s vectorized analytical engine. A search-then-aggregate log workflow (find all logs containing “OutOfMemoryError”, count by service, group by hour, calculate P99 latency) executes in a single engine pass. ClickHouse also notes that phrase search acceleration is planned for a future release; currently, multi-token search narrows the candidate set and phrase matching is completed with linear scanning over remaining granules.

ClickStack’s HyperDX UI also supports a Lucene-style search syntax for routine log queries, so teams do not need to write SQL directly for common filtering tasks.

Elasticsearch: Full-text search is Elasticsearch’s foundational architectural strength. Elasticsearch supports relevance ranking via BM25, fuzzy matching using Levenshtein distance algorithms, synonym handling, phonetic matching, and custom text analyzers per field, as documented on elastic.co’s full-text search documentation. These give Elasticsearch an advantage in scenarios where you need to find documents by approximate or semantically related terms rather than exact field matches.

For log analytics specifically, relevance ranking and fuzzy matching are rarely the primary requirement. Most log search is exact-field filtering (level:ERROR, service.name:api-gateway, trace_id:abc123), followed by aggregations. For these workflows, ClickHouse’s unified analytical engine performs faster than Elasticsearch’s general-purpose search architecture.

Elasticsearch also supports semantic search with dense and sparse vectors and hybrid retrieval, as documented. ClickHouse does not currently offer semantic search capabilities.

Storage efficiency

Both tools have improved storage efficiency significantly in recent versions. The gap is narrower than it was in 2023.

ClickHouse: ClickHouse’s columnar storage with ZSTD compression delivers 8x to 12x compression on typical observability data. According to ClickHouse’s own April 2026 benchmark, which is fully reproducible with source data and scripts published in a public GitHub repository, ClickHouse stored a 50-billion-row OpenTelemetry log dataset more compactly than Elasticsearch at every tested scale. ClickHouse’s comparison page for Elastic Observability claims 3x better compression versus Elastic and 4x overall cost reduction.

Elasticsearch: Elasticsearch’s logsdb index mode, generally available since Elasticsearch 8.17, and now enabled by default for all new log data streams in Elastic Stack 9.0 and Elastic Cloud Serverless, reduces log storage significantly. As documented on elastic.co’s logs data stream page: “In benchmarks, logsdb index mode reduced the storage footprint of log data by up to 60%, with a small impact (10-20%) to indexing performance. Results vary depending on your data set and Elasticsearch version.”

The Enterprise tier with synthetic _source enabled has shown up to 77% storage reduction in Elastic’s own nightly benchmarks, as documented on Elastic Observability Labs. Logsdb achieves compression through smart index sorting, synthetic _source (which reconstructs original JSON on demand rather than storing it), ZSTD compression, delta encoding, and run-length encoding.

The key nuance: the 77% figure requires the Enterprise tier and synthetic _source. The broadly applicable GA claim is up to 60%, with results varying by dataset. ClickHouse’s compression advantages apply across all tiers without feature restrictions.

Query performance

According to ClickHouse’s April 2026 self-published benchmark, ClickHouse outperforms Elasticsearch by 2 to 6 times across the full-text analytical workload on OpenTelemetry log data at scales from 1 billion to 50 billion rows. The benchmark tests a combined search-then-aggregate pattern: full-text search followed by counting, grouping by service, time-range filtering, and isolating hosts. This is where ClickHouse’s unified engine architecture has the largest structural advantage over Elasticsearch’s separate search and aggregation phases.

Elastic acknowledges ongoing query performance work. Four targeted query engine optimizations across the 9.x release series have delivered 40% better latency since January 2026. A doc-values-only mode that skips inverted indexes and BKD trees entirely to deliver near-columnar storage density is described on the same page as shipping later in 2026.

Query languages

ClickHouse: Standard SQL across all data. ClickHouse supports full SQL including joins, subqueries, window functions, and over 100 built-in analytical functions. ClickStack’s HyperDX UI adds a Lucene-style search syntax layer for routine observability queries without requiring SQL.

Elasticsearch: Elasticsearch supports four query interfaces:

• ES|QL (Elasticsearch Query Language): Elastic’s piped query language for filtering, transforming, and analyzing data. Powered by a separate query engine with concurrent processing.
• Query DSL: Elasticsearch’s original JSON-based query language, rich in filters, aggregations, and full-text search options.
• EQL (Event Query Language): A query language for event-based time-series data, well-suited for log and security use cases.
• SQL: A native SQL interface, which brings SQL familiarity to Elasticsearch’s search and relevance capabilities.

Elasticsearch’s multiple query languages reflect its broad set of use cases. For log analytics specifically, ES|QL and Query DSL are the primary interfaces teams use.

Schema and data model

ClickHouse: ClickHouse is a relational database requiring a defined schema. Log tables need a schema upfront, or teams can use the schema-agnostic OTel schema that ClickStack provides out of the box. ClickHouse handles high-cardinality fields natively without mapping explosion and supports over 90 file formats for ingestion.

Elasticsearch: Elasticsearch does not require structured data at ingest time. Dynamic mapping detects field types automatically, making it fast to get started with unstructured or semi-structured log data. However, dynamic mapping can lead to mapping explosion when logs contain high-cardinality field names (for example, when field names include user IDs or request parameters), which degrades query performance and increases memory consumption.

Ingest and ecosystem

ClickHouse: ClickHouse supports over 100 integrations and accepts data via OTLP, HTTP, the ClickHouse native protocol, Kafka, and S3. ClickStack adds a pre-configured OpenTelemetry Collector for zero-config log ingest from OTel-instrumented applications.

Elasticsearch: Elasticsearch has a mature, large ecosystem. Elastic Observability now recommends Elastic Agent and OpenTelemetry Protocol ingestion as the primary collection path, with support for Prometheus remote write via native PromQL support. Elasticsearch also ingests directly via Logstash, Elastic Beats (Filebeat, Metricbeat, and others), and hundreds of pre-built integrations.

Licensing

Component	ClickHouse	Elasticsearch
Database/engine	Apache 2.0	Triple-licensed: Elastic License 2.0, SSPL, AGPLv3
Default distribution	Apache 2.0	Elastic License 2.0
Visualization	HyperDX (MIT, via ClickStack)	Kibana: same triple license

The licensing picture for Elasticsearch changed in September 2024. Elastic added AGPLv3 as a third licensing option alongside Elastic License 2.0 and SSPL. The default distribution remains under Elastic License 2.0.

Elastic License 2.0 is not an OSI-approved open-source license. It allows free use, modification, redistribution, and derivative works with three restrictions: you may not provide the products to others as a managed service, you may not circumvent license key functionality, and you may not remove licensing notices. For teams using Elasticsearch internally for log analytics, these restrictions have no practical impact. For teams building managed observability services on top of Elasticsearch, they do.

ClickHouse’s Apache 2.0 license has no such restrictions.

When to choose ClickHouse for logs

ClickHouse is the stronger choice when:

• Your log workload is primarily aggregation-heavy: counting, grouping, filtering, and percentile calculations across large time ranges
• You are ingesting OpenTelemetry structured logs and want the ClickStack observability stack out of the box
• You need SQL access to your log data for custom analysis, cost attribution, or compliance reporting
• Storage cost and long-term retention at the petabyte scale are a primary concern
• You are co-locating log analytics with metrics and traces, and want a single backend for all signal types
• Your team is comfortable with a schema-defined data model and SQL

When to choose Elasticsearch for logs

Elasticsearch is the stronger choice when:

• Your log workload requires relevance-ranked full-text search, fuzzy matching, synonym handling, or unstructured text exploration
• You have an existing ELK stack infrastructure and a significant investment in Kibana dashboards, Logstash pipelines, and Elastic Beats configuration
• Your use case extends beyond log analytics into security (SIEM), threat hunting, or enterprise search, where Elasticsearch’s broader query capabilities matter
• You need a semantic search over log data using dense or sparse vector embeddings
• Your team has existing Elasticsearch operational expertise and does not want to migrate

Where CubeAPM fits for observability teams

For engineering teams evaluating ClickHouse vs Elasticsearch specifically for application logs in an observability context, the underlying database is only part of the decision. You also need an APM layer that surfaces service performance, error rates, latency distributions, and deployment-correlated health views on top of the log data.

CubeAPM is a self-hosted, OpenTelemetry-native APM platform that works with ClickHouse as its backend. It accepts standard OTLP input, the same format both ClickHouse and Elasticsearch ingest, and adds structured APM workflows on top: service maps, latency percentile dashboards, error tracking, and trace-to-log correlation. Pricing is ingestion-based at $0.15/GB with no per-host, per-user, or per-series fees.

For teams choosing ClickHouse for log storage, CubeAPM provides the APM visibility layer without requiring you to build and maintain custom dashboards or manage a separate observability frontend.

Summary

ClickHouse and Elasticsearch have both narrowed each other’s historical advantages. ClickHouse added full-text search that went GA in version 26.2 (March 2026) and runs 2 to 6 times faster than Elasticsearch for the analytical log workload in ClickHouse’s own benchmark. Elasticsearch added logsdb index mode that reaches up to 60% storage reduction broadly and up to 77% in Enterprise mode, significantly closing the cost gap. Neither tool is categorically better for every log use case. The right answer depends on whether your workload is aggregation-first or relevance-search-first, whether you need semantic search and unstructured text exploration, and what your team already knows how to operate.

For teams building on OpenTelemetry who want structured APM on top of their log storage, CubeAPM adds the service-level performance layer at $0.15/GB ingested with no infrastructure lock-in.

Dimension	ClickHouse	Elasticsearch
Architecture	Columnar OLAP engine	Inverted index search engine (Lucene)
Full-text search	Yes (inverted index, GA in v26.2, March 2026); no relevance ranking	Yes (BM25 relevance ranking, fuzzy, synonyms, semantic)
Analytics performance	2 to 6x faster than Elasticsearch on analytical log workload (ClickHouse benchmark, April 2026)	40% latency improvement across 9.x series (Elastic, 2026)
Storage efficiency	8x to 12x columnar ZSTD compression	Up to 60% reduction with logsdb (all tiers); up to 77% with Enterprise mode synthetic _source
Schema model	Defined schema; handles high cardinality natively	Dynamic mapping; mapping explosion risk at high cardinality
License	Apache 2.0	Elastic License 2.0 (default); also SSPL and AGPLv3
Query languages	Standard SQL	ES
Semantic search	No	Yes (dense and sparse vectors, hybrid retrieval)
Phrase search acceleration	Planned (not yet GA)	Yes (native via inverted index)
Best for	Aggregation-heavy structured log analytics at scale	Relevance-ranked full-text search, unstructured logs, SIEM/security
Managed observability stack	ClickStack	Elastic Observability

Disclaimer: Performance and storage figures from ClickHouse’s benchmark are sourced from Elasticsearch and represent a self-published benchmark by ClickHouse. All information reflects publicly available documentation as of June 2026. Verify current details with each vendor before making infrastructure decisions. CubeAPM is referenced as a complementary tool; evaluate all platforms against your own requirements.

Also read:

ClickStack vs Grafana (LGTM): Which Observability Stack Should You Run in 2026?

ClickStack Alternatives in 2026: 6 Tools Compared for Self-Hosted and Managed Observability

ClickStack vs Elasticsearch: Which Observability Stack Should You Choose?