Why ClickHouse behaves the way it does. Each module takes one domain, names the property that governs it, and shows the problem that property was built to answer — then puts it next to PostgreSQL, Elasticsearch and Snowflake, so you know when ClickHouse is the right tool and when it is not.
Course · self-paced
ClickHouse Philosophy
How ClickHouse is different, domain by domain. Each property mapped to the problem it answers, with comparison matrices against other systems — where it excels, what it trades away, and when something else fits better.
- Modules
- 6
- Level
- Intermediate
- Status
- Open
6 domains
- 01 · STORAGE
Columnar parts
Answers: scanning billions of rows while reading only what the query needs.
Read the module → - 02 · INDEXING
Sparse index & granules
Answers: skipping data without an index as large as the table.
Coming later - 03 · EXECUTION
Vectorized pipelines
Answers: keeping every core busy on one query.
Coming later - 04 · INGESTION
Inserts as parts
Answers: high write throughput — and why many tiny inserts hurt.
Coming later - 05 · CHANGE
Mutations & merges
Answers: updating immutable data, and what it costs.
Coming later - 06 · DISTRIBUTION
Replication & shards
Answers: scaling out, and what Keeper coordinates.
Coming later
The comparison matrix
A sample. Every module ends with its own row set.
| Property | ClickHouse | PostgreSQL | Elasticsearch | Snowflake |
|---|---|---|---|---|
| Storage layout | Columnar parts (MergeTree) | Row heap | Inverted index + doc values | Columnar micro-partitions |
| Primary index | Sparse, one mark per granule | Dense B-tree, one entry per row | Inverted index per term | None; min/max pruning |
| Updating a row | Mutation rewrites parts | Cheap, MVCC row version | Delete + reindex document | DML rewrites micro-partitions |
| Deployment | Self-hosted or managed | Self-hosted or managed | Self-hosted or managed | Managed only |