ClickStack vs Elasticsearch: Which Observability Stack Should You Choose?

ClickStack and Elasticsearch are two of the most-discussed options when teams evaluate observability infrastructure for logs, metrics, and traces. On the surface they look similar: both store large volumes of time-stamped data, both surface that data through a query interface, and both connect to OpenTelemetry pipelines. But underneath, they are built on fundamentally different architectures, and that difference determines which one fits your workload.

ClickStack is powered by ClickHouse, a columnar analytical database originally developed at Yandex and now maintained by ClickHouse Inc. under the Apache 2.0 license. Elasticsearch, by contrast, is a distributed search engine built on Apache Lucene and developed by Elastic NV, released under the Server Side Public License (SSPL) since 2021. This guide breaks down the architecture, performance, cost, and use-case fit of each system so you can make an informed decision.

ClickStack vs Elasticsearch: At a Glance

The comparison above captures the headline differences. ClickStack (built on ClickHouse) is a columnar, analytics-first system. Elasticsearch is an inverted-index, search-first system. Everything else in this guide flows from that core distinction.

Architecture: Columnar vs Inverted Index

How ClickHouse (ClickStack) stores data

ClickHouse uses the MergeTree engine family, which stores data in columns rather than rows. Each column is compressed independently using algorithms like LZ4 or ZSTD, and rows are always sorted by a user-defined primary key. When a query filters by primary key fields, ClickHouse uses sparse primary indexes to skip irrelevant parts of each column, dramatically reducing disk I/O. Queries parallelize across all available CPU cores without JVM constraints.

The result is 10 to 20x compression compared to raw data and aggregation performance 10 to 100x faster than Elasticsearch for structured analytical workloads, based on benchmarks published by ClickHouse and verified by independent testing from sources including Greptime and Tasrie IT Services.

How Elasticsearch stores data

Elasticsearch stores data as JSON documents in Lucene-based inverted indices. Every ingested document is broken into tokens and indexed, allowing fast keyword lookups and BM25 relevance scoring. This design is excellent for full-text search but introduces significant storage overhead: indexing every field inflates on-disk size, and the Lucene segment model creates maintenance overhead through continuous background merges.

Elasticsearch partitions data into shards, each of which is a Lucene index. Shard sizing is constrained by JVM heap limits of approximately 64 GB per node, and queries parallelize only within shard boundaries. This forces horizontal scaling at a threshold where ClickHouse can still scale vertically.

Feature-by-Feature Comparison

Feature	ClickStack (ClickHouse)	Elasticsearch (ELK)
Storage model	Columnar (MergeTree engine)	Document store (inverted index / Lucene)
Primary use case	Analytical queries, log analytics, metrics	Full-text search, unstructured data
Query language	Standard SQL	Query DSL, EQL, KQL, ES|QL
Compression ratio	10 to 20x vs raw data	2 to 3x vs raw data
Ingestion rate	1 million+ events per second	100K to 500K events per second
Scale ceiling	Petabyte scale	Terabyte scale (JVM heap constraints)
License	Apache 2.0	Server Side Public License (SSPL) since 2021
OTel support	OpenTelemetry-native (first-party)	Added via plugin, proprietary agents still migrating
UI layer	HyperDX (open source)	Kibana (proprietary, Elastic license)
Machine learning	External integration	Built-in ML via X-Pack (paid)

Query Performance

The performance difference between ClickStack and Elasticsearch is most visible in analytical workloads. Independent benchmarks from sources including Greptime, OneUptime, and Tasrie IT Services show the following results on equivalent hardware:

Query Type	ClickHouse	Elasticsearch
Count logs across 1 billion rows	~0.5 seconds	3 to 5 seconds
Aggregation by field	~0.8 seconds	5 to 10 seconds
Time-series grouping	~0.3 seconds	2 to 4 seconds
Full-text search	2 to 5 seconds	0.5 to 1 second
Complex aggregations	1 to 2 seconds	10 to 30 seconds
Regex search	1 to 3 seconds	3 to 8 seconds

ClickHouse’s vectorized query engine processes aggregations across billions of rows in sub-second time. Elasticsearch term aggregations are approximate by default at scale and slow down under heavy cardinality. For full-text search specifically, Elasticsearch remains the stronger choice: BM25 relevance scoring, fuzzy matching, synonym handling, and phrase boosting are built into its Lucene foundation in ways that ClickHouse’s token-based hasToken() and bloom filter indexes do not replicate fully.

Storage Efficiency and Cost

Storage cost is often the deciding factor when teams migrate from Elasticsearch to ClickStack. ClickHouse’s columnar compression reduces on-disk storage dramatically compared to Elasticsearch’s document store approach.

Metric	ClickHouse	Elasticsearch
Raw log volume: 1TB	50 to 100 GB stored	300 to 500 GB stored
30-day retention (1TB/day)	~3 TB stored	~15 TB stored
Storage cost (100TB raw/month)	~$200/month	~$1,000/month
Compute cost (equivalent)	~$2,000/month	~$5,000/month
Total estimated monthly cost	~$2,500/month	~$8,000/month

Based on publicly available estimates, ClickHouse typically reduces storage infrastructure costs by 60 to 70% compared to equivalent Elasticsearch deployments for log analytics workloads. Canva, which migrated from OpenSearch (an Elasticsearch fork) to ClickHouse, reported 70% lower costs and 10x faster search performance after the move, according to ClickHouse’s own case study documentation.

A real-world deployment cited in ClickHouse’s documentation involved a logging cluster exceeding 400 physical nodes with peak write traffic above 40 GB per second. After migrating from Elasticsearch, machine costs decreased by 30% while query speed improved by approximately 4x.

The Full Stack: Components Side by Side

ClickStack and the Elastic Stack both cover the same functional roles in an observability platform. The table below maps how each system fills each role, based on the official ClickHouse documentation comparing ClickStack and Elastic.

Role	Elastic Stack	ClickStack
UI and alerting	Kibana	HyperDX
Storage and query engine	Elasticsearch	ClickHouse
Data collection	Elastic Agent, Beats (Filebeat, Metricbeat)	OpenTelemetry Collector
Instrumentation SDKs	Elastic APM agents (proprietary)	OpenTelemetry SDKs
ETL and data processing	Logstash, ingest pipelines	OTel Collector + ClickHouse materialized views

The most significant architectural difference beyond the storage engine is instrumentation philosophy. ClickStack is built on OpenTelemetry (OTel) end-to-end: collection, processing, and storage all follow OTel semantics. Elastic added OTel support to an existing proprietary ecosystem, and Elastic APM agents remain tied to the Elastic Stack. If your team is standardizing on OTel, ClickStack fits that strategy more naturally. 

Scalability

ClickStack scaling

ClickHouse scales vertically first, using all available CPU cores and RAM before requiring additional nodes. It supports horizontal sharding for extreme volumes, but the shard model is simpler to manage than Elasticsearch’s: there are no JVM heap limits, no segment merges to tune, and no rebalancing required after node additions. ClickHouse Cloud decouples compute from storage, allowing nodes to scale independently with data stored on S3. All nodes share a single copy of the data on object storage, reducing retention costs significantly.

Elasticsearch scaling

Elasticsearch scales horizontally through sharding. Each shard is a Lucene index bounded by approximately 50 GB or 200 million documents, based on Elastic’s own sizing guidance. Queries parallelize only within shard boundaries, and JVM heap limits of roughly 64 GB per node create a hard ceiling on single-node throughput. At scale, Elasticsearch requires constant shard rebalancing, JVM tuning, and careful index lifecycle management. According to the ClickHouse documentation, this architecture was designed for terabyte workloads and struggles as data grows toward petabyte scale.

Licensing

ClickHouse is released under the Apache 2.0 license. HyperDX, the UI layer in ClickStack, is MIT licensed. This means you can deploy, modify, and build commercial products on ClickStack without restrictions. 

Elasticsearch shifted from Apache 2.0 to the Server Side Public License (SSPL) in January 2021. SSPL imposes conditions on organizations that offer Elasticsearch as a service, requiring them to open-source the entire service stack. This change led AWS to fork Elasticsearch into OpenSearch under Apache 2.0. If your organization has strict open-source licensing requirements, ClickStack or OpenSearch are preferable to Elasticsearch. 

When to Choose ClickStack

• You ingest high-cardinality metrics, logs, or traces and need fast aggregation over large time windows.
• Storage cost is a constraint: columnar compression reduces on-disk footprint by 10 to 20x compared to raw data.
• Your team is adopting OpenTelemetry and wants a storage backend that aligns natively with OTel semantics.
• You need standard SQL for querying, rather than learning a proprietary query DSL.
• You are running petabyte-scale infrastructure and need to avoid JVM heap limitations.
• You want to correlate observability signals with business or application data in a single engine.

When to Choose Elasticsearch

• Full-text search quality is your primary requirement: BM25 relevance scoring, fuzzy matching, highlighting, and synonym expansion are first-class in Elasticsearch.
• Your team already uses the ELK stack and has invested in Kibana dashboards, Logstash pipelines, and Elastic APM.
• You need schema-on-read flexibility: Elasticsearch handles dynamic mappings and unstructured data ingestion more naturally than ClickHouse’s schema-bound MergeTree tables.
• Built-in machine learning anomaly detection (X-Pack) is important to your alerting strategy.
• You operate in an environment where Elasticsearch’s FedRAMP authorization or enterprise security compliance is required.

Migration Considerations

Teams migrating from Elasticsearch to ClickStack typically face three main transition tasks. First, schema definition: ClickHouse requires an explicit table schema at creation time, unlike Elasticsearch’s dynamic mappings. Planning column types and primary keys upfront avoids costly backfills later. Second, ingestion pipeline changes: Logstash and Beats pipelines need to be replaced or supplemented with OpenTelemetry Collector configurations. Third, query rewrites: Kibana dashboards using Query DSL need to be rebuilt in HyperDX or another ClickHouse-compatible interface.

ClickHouse recommends sizing batch inserts carefully. Small inserts are a known performance risk: too many small batches create excessive part counts (TOO_MANY_PARTS errors) that slow ingestion and may require data drops to resolve. Production deployments often place a message queue such as Kafka or Redpanda between the data source and ClickHouse to smooth out ingestion. Source: r/Observability community discussion on ClickStack deployment practices.

Conclusion

ClickStack and Elasticsearch serve different primary purposes. Elasticsearch is a search engine first, and it remains the best choice when full-text search quality, BM25 relevance, and fuzzy matching are the core requirements. ClickStack is a columnar analytics platform first, and it is the stronger choice when you need fast aggregations over high-cardinality data at scale, lower storage costs, and native OpenTelemetry support.

For most modern observability workloads dominated by structured log analytics, metric correlation, and distributed traces, the architectural advantages of ClickHouse make ClickStack the more efficient and cost-effective option. For search-heavy use cases where relevance and text analysis matter more than aggregation speed, Elasticsearch remains a viable and mature choice.

⚠️ DisclaimerPricing figures and benchmark numbers cited in this article are sourced from publicly available documentation, independent benchmarks, and vendor comparison pages as of June 2025. Actual performance and costs vary depending on cluster configuration, data volume, query patterns, and deployment environment. Always validate figures against the latest official documentation before making infrastructure decisions.

FAQs