Education

Managed ClickHouse, Explained: the options and what actually decides performance

April Wong

July 14, 20265 min read

Managed ClickHouse, Explained: the options and what actually decides performance

TL;DR

ClickHouse is the default open-source engine for analytics: columnar storage, sequential scans, vectorized execution. Free to download; the real decision is who operates it and what it runs on.
For the big-scan queries ClickHouse is built around, sustained storage throughput is usually the first bottleneck you feel, not CPU and not headline IOPS.
Three ways to run it: self-hosted (total control, total responsibility), first-party SaaS (ClickHouse Cloud: serverless, S3-backed, with an optional BYOC variant), or independent managed providers (Altinity: hosted, BYOC, and more recently BYOK).
Managed means you shed the cluster-infrastructure pager but keep the levers that matter: schema, sort orders, codecs, queries.
The variable both models share and most teams leave on defaults: infrastructure. Storage throughput and where the database sits relative to the workload quietly set your performance ceiling.
Part two, on that second question, later this week.

ClickHouse is free to download. That was never the decision. The decision is who operates it, and what it runs on.

What is ClickHouse?

ClickHouse is an open-source database built for analytics. It was created to power web analytics at scale, open-sourced in 2016, and is now developed by ClickHouse Inc. alongside a large open-source community. A general-purpose database like Postgres or MySQL is tuned to read and write individual records. ClickHouse is an OLAP engine: it is built to scan huge volumes of data and answer analytical questions, aggregations, filters, and rankings over millions or billions of rows, quickly.

It has become the default wherever a query must read a lot of data and answer fast: dashboards, observability, real-time bidding, fintech backtesting, on-chain analytics. It earned that for mechanical reasons worth understanding, because those mechanics are what every deployment choice below has to protect.

Why ClickHouse is fast

Traditional databases store data row by row: all of a record's fields sit together on disk. That is ideal for reading or writing one whole record at a time, which is why row stores power transactional apps. For analytics it is wasteful. A query that scans billions of rows to read a few columns still has to pull every field off disk for every row, because they are interleaved, then throw away everything it did not need.

Let's break that down. Picture your data as a notebook. A traditional database writes one customer per line: name, email, country, purchase amount, and dozens more fields. That is a row store, and it is perfect when you need everything about one customer: grab the line, done. But ask "add up all the purchase amounts" and the layout fights you. Each amount sits in the middle of a full line, so the database reads every field of every line to keep one. Across billions of lines, most of the work was reading things nobody asked for.

ClickHouse writes the notebook differently: a separate list for every field. That is a column store. "Add up the amounts" now means opening one list and reading straight down; the rest stay closed. Three things speed it up further: each list compresses well because similar values sit together, a sparse index lets whole sections be skipped, and values are processed in large batches that modern CPUs chew through. The mirror-image tradeoff: showing everything about one customer means opening every list, where a row store grabs one line. Columnar for analytics, row for transactions.

Notice what "reading a list straight down" means at the hardware level: one long sequential read. That is why, for the big scans that define analytical use, sustained storage throughput is usually the bottleneck you feel first. Queries can still be CPU-bound, and latency and IOPS matter for selective, concurrent, and merge-heavy workloads, but the scan path lives on how fast columnar data streams off storage.

The options

A production database is one somebody operates. The options run from most hands-on to least:

Self-hosted Open Source – you own DB + infra.
ClickHouse Cloud (fully managed) – ClickHouse Inc. owns DB + infra (with an optional BYOC variant on AWS and GCP, aimed at large committed contracts).
Independent managed providers – they own DB; infra can be theirs, yours (BYOC), or your K8s (BYOK).

"Managed ClickHouse" means either of the last two: someone else runs the operations, and you still design the schema and queries. Which model you pick also decides where your data physically sits and what it runs on, a point we will come back to.

Why managed ClickHouse?

Downloading ClickHouse is easy. Everything after that is the job: sort orders, codecs, partition keys, merge tuning, replication, upgrades that cannot drop queries, and the pager when a merge storm hits at 3am. A managed provider like Altinity (an independent specialist running production ClickHouse since 2017) takes that machinery, watches it around the clock, and helps tune your tables and queries, while the design choices stay yours: you shed the pager, not the design work. Self-host if operating ClickHouse is a core competency you want to own; for everyone else, managed is often cheaper once engineering time and on-call are counted.

Here is the part that is easy to miss. Managed or self-hosted, ClickHouse still runs on infrastructure, and that infrastructure is a real variable, not a detail. The default just looks different depending on the path. Run ClickHouse on block storage (self-hosted, or a classic managed deployment in your cloud account) and the default AWS volume is gp3: 125 MiB/s and 3,000 IOPS unless you pay to raise it. Run it on object storage (the ClickHouse Cloud model) and the numbers flip: request rates scale nearly without limit, but every uncached read is an HTTP round trip measured in tens of milliseconds, which is why that model leans hard on local SSD caches. Different defaults, same lesson: for read-heavy scans over uncached data, storage is usually the ceiling that bites first.

Placement is the other forgotten lever. Put the workload in one region and the database in another, and one question means three round trips across the network (data in, query over, answer back), with latency compounding at every hop and transfer charges at every border. Run both in the same region and VPC and that tax mostly disappears; the storage ceiling stays.

So the choice is really two questions. Who operates the engine: a staffing decision. What it runs on: an architecture decision, and it quietly sets your ceiling.