analytics

ClickHouse

ClickHouse is a analytics product that columnar store built for aggregation. This profile covers what it does, how it is priced, and where it stops being the right choice.

What the product actually does

ClickHouse is a columnar database built for aggregation over large volumes. The design assumption is that you will scan many rows and return few, which is the opposite of a transactional database's assumption. On analytical queries over hundreds of millions of rows it is dramatically faster than a row-store, and the gap widens as volume grows.

The other defining property is that it is boringly reliable under load. ClickHouse was built inside Yandex to serve analytics at a scale where a query planner mistake is a production incident, and that heritage shows in how it behaves when a query is badly written: it usually finishes, just slowly.

How pricing works once you are inside

Open source is free. ClickHouse Cloud prices on compute and storage separately, which is the right model for an analytical workload but requires you to understand your query concurrency. Compute scales with concurrent queries; storage scales with retained data. A workload with high concurrency and small data costs very different money from one with low concurrency and large data.

The cost trap is leaving compute running for a workload that runs four times a day. Idle compute is billed, and teams that move from a self-hosted instance to cloud without right-sizing discover the bill reflects their old always-on habit.

Where it breaks down

Point updates and deletes are the weak spot. ClickHouse handles them through asynchronous merges, which means an update is not immediately visible and a high-frequency update pattern degrades badly. If your workload is update-heavy — a CRM, an inventory system — ClickHouse is the wrong tool and no amount of tuning fixes it.

Joins are also limited relative to a traditional warehouse. ClickHouse can join, but the optimiser assumes the right-hand side is small enough to broadcast. Large-large joins perform poorly and the usual answer is to denormalise, which is a schema decision you have to make early.

What switching costs

Moderate to high. SQL is close enough to standard that queries port, but the schema design — sort keys, partitioning, materialised views — is ClickHouse-specific and does not transfer. A mature ClickHouse schema represents real design work.

Who should not use it

Transactional workloads, and teams without someone who understands how columnar storage behaves. ClickHouse punishes schema decisions made by analogy to Postgres.

Sources

ClickHouse public documentation, pricing page and engineering blog, read October 2026.