ClickHouse documentation
On a 29.5-million-row table, a filter on the primary key reads 3 of 3,609 granules — about 25,000 rows. The pages below explain how that happens and how to build tables that behave the same way.
Run a server locally with one command
Create a MergeTree table, insert rows, read them back
Columnar storage, granules, and the sparse index
How inserts become parts and parts become merges
Why the index fits in memory and skips whole granules
ReplacingMergeTree, SummingMergeTree, and the rest of the family
LowCardinality, Nullable, DateTime64, JSON
The decision that makes queries 4x faster
Batch sizes, async inserts, and the Too many parts error
Insert triggers that keep aggregates current
PREWHERE, projections, skip indexes, EXPLAIN
Halve your storage by fixing types and codecs
The system tables that answer operational questions
Kafka, S3, Postgres, MySQL, dbt, Grafana
Query ClickHouse over REST from any language
Logs, traces, and metrics on ClickHouse with HyperDX
The ClickHouse engine embedded in your own process
What ClickHouse is for#
ClickHouse fits workloads that scan and aggregate large volumes of data: real-time analytics dashboards, observability and log storage, business intelligence, machine-learning feature stores, and any product that reports over event data.
It is not designed as a transactional store. Single-row lookups by id, frequent updates of individual rows, and high-rate small writes all run against the grain of its design. Read why ClickHouse is fast to see which trade-offs produce that speed.
The server is open source under the Apache 2.0 license, and runs anywhere from a laptop binary to a replicated multi-region cluster. ClickHouse Cloud runs the same engine with storage and compute separated and scaling handled for you.
ClickHouse Cloud sizes, scales, backs up and upgrades the service for you.