Equivalent concepts in ClickStack and Elastic

[Edit this page](https://github.com/ClickHouse/clickhouse-docs/blob/main/docs/use-cases/observability/clickstack/migration/elastic/concepts.md)

## Elastic Stack vs ClickStack[​](#elastic-vs-clickstack "Direct link to Elastic Stack vs ClickStack")

Both Elastic Stack and ClickStack cover the core roles of an observability platform, but they approach these roles with different design philosophies. These roles include:

- **UI and Alerting**: tools for querying data, building dashboards, and managing alerts.
- **Storage and Query Engine**: the backend systems responsible for storing observability data and serving analytical queries.
- **Data Collection and ETL**: agents and pipelines that gather telemetry data and process it before ingestion.

The table below outlines how each stack maps its components to these roles:

|  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| **Role** **Elastic Stack** **ClickStack** **Comments**|  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | **UI & Alerting** **Kibana** — dashboards, search, and alerts **ClickStack UI (HyperDX)** — real-time UI, search, and alerts Both serve as the primary interface for users, including visualizations and alert management. The ClickStack UI is purpose-built for observability and tightly coupled to OpenTelemetry semantics.|  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | **Storage & Query Engine** **Elasticsearch** — JSON document store with inverted index **ClickHouse** — column-oriented database with vectorized engine Elasticsearch uses an inverted index optimized for search; ClickHouse uses columnar storage and SQL for high-speed analytics over structured and semi-structured data.|  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | **Data Collection** **Elastic Agent**, **Beats** (e.g. Filebeat, Metricbeat) **OpenTelemetry Collector** (edge + gateway) Elastic supports custom shippers and a unified agent managed by Fleet. ClickStack relies on OpenTelemetry, allowing vendor-neutral data collection and processing.|  |  |  |  |  |  |  |  |  |  |  |  | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | **Instrumentation SDKs** **Elastic APM agents** (proprietary) **OpenTelemetry SDKs** (distributed by ClickStack) Elastic SDKs are tied to the Elastic stack. ClickStack builds on OpenTelemetry SDKs for logs, metrics, and traces in major languages.|  |  |  |  |  |  |  |  | | --- | --- | --- | --- | --- | --- | --- | --- | | **ETL / Data Processing** **Logstash**, ingest pipelines **OpenTelemetry Collector** + ClickHouse materialized views Elastic uses ingest pipelines and Logstash for transformation. ClickStack shifts compute to insert time via materialized views and OTel collector processors, which transform data efficiently and incrementally.|  |  |  |  | | --- | --- | --- | --- | | **Architecture Philosophy** Vertically integrated, proprietary agents and formats Open standard–based, loosely coupled components Elastic builds a tightly integrated ecosystem. ClickStack emphasizes modularity and standards (OpenTelemetry, SQL, object storage) for flexibility and cost-efficiency. | | | | | | | | | | | | | | | | | | | | | | | | | | | |

ClickStack emphasizes open standards and interoperability, being fully OpenTelemetry-native from collection to UI. In contrast, Elastic provides a tightly coupled but more vertically integrated ecosystem with proprietary agents and formats.

Given that **Elasticsearch** and **ClickHouse** are the core engines responsible for data storage, processing, and querying in their respective stacks, understanding how they differ is essential. These systems underpin the performance, scalability, and flexibility of the entire observability architecture. The following section explores the key differences between Elasticsearch and ClickHouse - including how they model data, handle ingestion, execute queries, and manage storage.

## Elasticsearch vs ClickHouse[​](#elasticsearch-vs-clickhouse "Direct link to Elasticsearch vs ClickHouse")

ClickHouse and Elasticsearch organize and query data using different underlying models, but many core concepts serve similar purposes. This section outlines key equivalences for those familiar with Elastic, mapping them to their ClickHouse counterparts. While the terminology differs, most observability workflows can be reproduced - often more efficiently - in ClickStack.

### Core structural concepts[​](#core-structural-concepts "Direct link to Core structural concepts")

|  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| **Elasticsearch** **ClickHouse / SQL** **Description**|  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | **Field** **Column** The basic unit of data, holding one or more values of a specific type. Elasticsearch fields can store primitives as well as arrays and objects. Fields can have only one type. ClickHouse also supports arrays and objects (`Tuples`, `Maps`, `Nested`), as well as dynamic types like [`Variant`](/docs/sql-reference/data-types/variant) and [`Dynamic`](/docs/sql-reference/data-types/dynamic) which allow a column to have multiple types.| **Document** **Row** A collection of fields (columns). Elasticsearch documents are more flexible by default, with new fields added dynamically based on the data (type is inferred from ). ClickHouse rows are schema-bound by default, with users needing to insert all columns for a row or subset. The [`JSON`](/docs/integrations/data-formats/json/overview) type in ClickHouse supports equivalent semi-structured dynamic column creation based on the inserted data.| **Index** **Table** The unit of query execution and storage. In both systems, queries run against indices or tables, which store rows/documents.|  |  |  |  |  |  | | --- | --- | --- | --- | --- | --- | | *Implicit* Schema (SQL) SQL schemas group tables into namespaces, often used for access control. Elasticsearch and ClickHouse don't have schemas, but both support row-and table-level security via roles and RBAC.|  |  |  | | --- | --- | --- | | **Cluster** **Cluster / Database** Elasticsearch clusters are runtime instances that manage one or more indices. In ClickHouse, databases organize tables within a logical namespace, providing the same logical grouping as a cluster in Elasticsearch. A ClickHouse cluster is a distributed set of nodes, similar to Elasticsearch, but is decoupled and independent of the data itself. | | | | | | | | | | | | | | | | | |

### Data modeling and flexibility[​](#data-modeling-and-flexibility "Direct link to Data modeling and flexibility")