What is ClickHouse?What is ClickHouse?
Fast open-source column-oriented database for real-time analytics and OLAP
ClickHouse in 60 seconds
A free, open-source column-oriented database built for online analytical processing, scanning billions of rows in a fraction of a second.
It answers analytical queries over billions of rows in real time, at ingest rates and compression a general-purpose database cannot match.
- +Columnar storage and vectorized execution scan billions of rows fast
- +MergeTree engine ingests millions of rows per second on one node
- +Speaks SQL over its native, HTTP, MySQL, and Postgres protocols
- −No full ACID transactions, so it is not built for OLTP workloads
- −Updates and deletes run as async mutations, not cheap row writes
- −Eventual consistency across replicas, no strict multi-row guarantees
At a glance
| Category | Analytics |
| First released | 2016 |
| Latest release | 26.7.4.58 (Aug 2026) |
| License | Apache-2.0 |
| Written in | C++ |
| Runs on | Linux, Macos |
| Deployment | Self-hosted, Managed |
| Wire protocol | clickhouse-native, http, mysql, postgresql |
| Query dialect | clickhouse-sql |
| Consistency | eventual |
| ACID support | no |
| JSON support | native |
| Full-text search | native |
| Vector support | native |
| HA model | primary-standby |
| Managed by | clickhouse-cloud, altinity, double-cloud |
What is ClickHouse?
ClickHouse is a free, open-source column-oriented database built for online analytical processing (OLAP). It stores each column separately and runs queries with a vectorized engine, so aggregations, filters, and group-bys over billions of rows return in a fraction of a second. It speaks SQL, and where a transactional database is tuned for many small reads and writes of single rows, ClickHouse is tuned for scanning huge tables to answer analytical questions in real time.
The technology started at Yandex, the Russian search company, where Alexey Milovidov began it in 2009 to power Yandex.Metrica, a web analytics product that handles traffic data at scale. It went into production there in 2012 and was open-sourced under the Apache 2.0 license in 2016. In 2021, Aaron Katz, Alexey Milovidov, and Yury Izrailevsky founded ClickHouse Inc. in the San Francisco Bay Area to develop it and run a managed cloud service.
ClickHouse has become a default for real-time analytics and observability. Cloudflare stores trillions of rows of HTTP request data in it, Uber and eBay run it for internal analytics, and devtools like Sentry and PostHog build their event pipelines on it. It runs self-hosted on a single node or across a large cluster, and as a managed service through ClickHouse Cloud and providers like Altinity.
How ClickHouse works
ClickHouse is a client-server database. A server process listens for queries over several protocols at once: its own native TCP protocol, an HTTP interface, and MySQL and PostgreSQL wire protocols so existing clients can connect. You talk to it in SQL through clickhouse-client, a driver, or a plain HTTP request. Unlike a row store, it never loads a whole row to answer a query; it reads only the columns a query actually names.
The main table engine is MergeTree. Rows are sorted by a primary key and written in immutable parts, and a background process continually merges small parts into larger ones. Data is split into granules and each column is compressed on disk, so a query reads a sparse index to skip past the parts and granules it does not need. Inserts are appended in batches rather than one row at a time, which is why ClickHouse ingests millions of rows per second.
Query execution is vectorized: the engine processes columns in blocks of thousands of values, keeping the CPU cache warm and using SIMD instructions across cores. For scale, tables are sharded across nodes and replicated through ClickHouse Keeper, a built-in coordination service that replaces ZooKeeper. Materialized views precompute rollups as data arrives, and MergeTree variants like ReplacingMergeTree and SummingMergeTree collapse or aggregate rows during merges.
Key concepts
MergeTree engine
MergeTree is ClickHouse's core table engine. It keeps rows sorted by a primary key and writes them in immutable parts that a background thread merges into larger ones. A sparse index lets a query skip parts and granules it never needs, and variants like ReplacingMergeTree and SummingMergeTree collapse or sum rows as they merge.
Columnar storage
ClickHouse stores each column of a table in its own file instead of keeping whole rows together. A query that touches a few columns reads only those, moving far less data off disk. Because every value in a column shares one type and often repeats, columns compress tightly with codecs like LZ4 and ZSTD, cutting storage and speeding scans.
Vectorized execution
Rather than processing one row at a time, ClickHouse runs queries over blocks of thousands of column values at once. These vectors stay in the CPU cache and let the processor apply SIMD instructions to many values in one step. Aggregations, filters, and joins spread across all cores, which is what makes billion-row scans finish fast.
Sharding and replication
To scale past one machine, ClickHouse splits a table into shards spread across nodes and keeps replicas of each shard for availability. A distributed table fans a query out to every shard and merges the results. Replication runs through ClickHouse Keeper, a built-in service that speaks the ZooKeeper protocol, so replicas stay in sync.
Materialized views
A materialized view in ClickHouse is an insert trigger, not a cached query. As rows land in a source table, the view runs its SELECT and writes the result into a target table, so rollups stay current with no scheduled job. Paired with a SummingMergeTree target, views precompute the summaries that dashboards read back instantly.
SQL and data types
ClickHouse speaks a SQL dialect close to standard SQL with analytical extensions. Its type system is rich: fixed-width integers, LowCardinality for repeated strings, Nested and Array columns, and a native JSON type. Hundreds of functions cover approximate counts, quantiles, and windows, and engines like Kafka read streams into tables.
ClickHouse by the numbers
Live GitHub adoption, updated daily
Who uses ClickHouse
A handful of the companies running it in production
When to use ClickHouse
Best for
Power dashboards that aggregate billions of events with sub-second response. ClickHouse scans and groups huge tables fast enough to feel interactive, so people slice metrics live instead of waiting on a batch.
Store logs, traces, and metrics at volumes that overwhelm a general database. High ingest and strong compression keep months of telemetry queryable and cheap, which is why many observability tools build on it.
Track user events, page views, and product usage across large user bases. ClickHouse ingests millions of events per second and answers funnel and retention queries over full history with no pre-aggregation.
Serve as a fast, low-cost warehouse for reporting and business intelligence. Wide fact tables with many columns compress well and scan fast, and materialized views precompute the rollups that BI tools read.
Not ideal for
ClickHouse has no full ACID transactions and is not built for small single-row reads and writes. For order processing, user accounts, and app state, a row store like Postgres or MySQL fits the work far better.
Updates and deletes run as background mutations that rewrite whole parts, not cheap row-level edits. Data that keeps changing after it lands is awkward here, where the engine expects append-only inserts.
Fetching one row by its key is a job for a key-value store or an OLTP database, not a columnar scanner. ClickHouse is tuned for reading many rows at once, so single-record lookups suit none of its strengths.
Replication is eventually consistent, with no multi-row guarantees across a cluster. Workloads needing every replica to agree instantly, like ledgers or inventory counts, want a strongly consistent store.
ClickHouse vs alternatives
Head-to-head specs against the top 5 alternatives
| Spec | ||||||
|---|---|---|---|---|---|---|
| Identity | ||||||
| License | Apache-2.0 | Proprietary | PostgreSQL License | MIT | Proprietary | Elastic-2.0 |
| First released | 2016 | 2014 | 1996 | 2019 | 2013 | 2010 |
| Capabilities | ||||||
| Consistency | Eventual | Strong | Strong | Strong | Strong | Eventual |
| HA model | Primary-standby | None | Primary-standby | None | None | Primary-standby |
| JSON | Native | Native | Native | Native | Native | Native |
| Ecosystem | ||||||
| Managed providers | 3 | 1 | 9 | 1 | 1 | 3 |
| Integrations | 7 | 8 | 8 | 6 | 8 | 6 |
| Use cases | ||||||
| Best for | Real-time analytics, log and event analytics, OLAP queries over billions of rows | Large-scale analytics, data warehousing, cross-cloud data sharing, and multi-cluster concurrent workloads | General-purpose OLTP, complex queries with advanced SQL, geospatial data with PostGIS, and applications requiring strong ACID compliance | Local OLAP queries, data science workflows, embedded analytics, and Parquet/CSV processing | Unified analytics and ML on a lakehouse architecture, large-scale ETL, and collaborative data science | Full-text search, log analytics, observability, security analytics, and real-time data exploration at scale |
| Not ideal for | OLTP workloads, frequent small updates/deletes, or applications requiring strict ACID transactions | OLTP transactional workloads, low-latency point lookups, or cost-sensitive small-scale projects | Extreme write-heavy workloads at massive horizontal scale, simple key-value caching, or real-time streaming without extensions | Multi-user server workloads, OLTP applications, or distributed analytics at massive scale | Simple OLTP workloads, low-latency point queries, or small-scale projects where a traditional database suffices | Primary data storage for transactional workloads, strong-consistency requirements, or simple key-value use cases |
Quick start
Run ClickHouse in Docker, connect with clickhouse-client, and run a first analytical query. Under a minute if you have Docker.
docker run -d --name clickhouse -p 8123:8123 -p 9000:9000 clickhouse/clickhouse-serverdocker exec -it clickhouse clickhouse-clientCREATE TABLE events (
event_time DateTime,
user_id UInt64,
event_type String,
country LowCardinality(String)
)
ENGINE = MergeTree
ORDER BY (event_time, user_id);
INSERT INTO events VALUES
(now(), 1, 'click', 'US'),
(now(), 2, 'view', 'DE');SELECT country, count() AS events
FROM events
GROUP BY country
ORDER BY events DESC;That is a working analytical database. Connect from any language with the official drivers, or point a BI tool or SQL GUI at the HTTP interface on port 8123.
Resources
Official
Community
Related database guides
DuckDB
Fast in-process analytical database with rich SQL support and zero dependencies
PostgreSQL
The world's most advanced open-source relational database
MongoDB
The most popular document database for modern applications
Qdrant
High-performance open-source vector database for next-generation AI applications
Turso
In-process SQL database compatible with SQLite, written in Rust with vector search and CDC support
Typesense
Fast, typo-tolerant open-source search engine with built-in vector and semantic search
Frequently asked questions
What is ClickHouse used for?
Is ClickHouse free?
Who created and owns ClickHouse?
Is ClickHouse a SQL or NoSQL database?
Is ClickHouse an OLAP or OLTP database?
Skip the config files
Connect to ClickHouse in 30 seconds. Browse tables, run queries, and edit rows visually, on localhost, self-hosted, or cloud.
Open ClickHouse in 1bench