Self-hosting vs ClickHouse Cloud
What you operate#
| Self-hosted | ClickHouse Cloud | |
|---|---|---|
| License | Apache 2.0, free | Usage-based, see pricing |
| Servers | You provision and size them | Managed |
| Replication | You run ReplicatedMergeTree plus a Keeper ensemble | Built in via SharedMergeTree |
| Scaling | Manual resizing and resharding | Automatic vertical and horizontal scaling |
| Backups | You configure BACKUP/RESTORE or clickhouse-backup |
Automated |
| Upgrades | You plan and execute them | Automatic patching |
| Idle cost | Full server cost, always | Scales to zero |
| Support | Community | Included, response time by plan |
The architectural difference#
Self-hosted ClickHouse stores data on the servers that query it. Replication means each replica holds a full copy, coordinated through ClickHouse Keeper or ZooKeeper. Adding a replica copies data.
ClickHouse Cloud separates compute from storage. Data lives in object storage (S3, GCS, or Azure Blob) and compute nodes are stateless. The Cloud-only SharedMergeTree engine replaces ReplicatedMergeTree transparently:
-- What you write
ENGINE = MergeTree
-- What Cloud substitutes
ENGINE = SharedMergeTree('/clickhouse/tables/{uuid}/{shard}', '{replica}')The behaviour and query interface remain the same. Because every replica reads the same data in object storage, adding a replica copies nothing, and compute can scale to zero while the data stays put.
Cloud also adds compute-compute separation on the Scale and Enterprise plans, so an ingestion workload and an analytics workload stop competing for the same resources.
Choose self-hosted when#
- Your data cannot leave your infrastructure, and BYOC does not resolve it.
- You already operate stateful distributed systems and have the on-call capacity.
- Sustained, predictable load makes owned hardware cheaper than usage-based billing.
- You need a version, build, or patch of your own.
Choose Cloud when#
- Load is bursty or unpredictable, and scale-to-zero avoids paying for idle capacity.
- Nobody on the team wants to own Keeper quorums, resharding, and upgrade windows.
- You need compliance certifications without building the controls yourself.
- Time to first query matters more than infrastructure control.
Running it yourself#
Install from deb or rpm packages, Docker, Kubernetes with the ClickHouse operator, or a source build. See install ClickHouse.
A production self-hosted cluster involves:
- ClickHouse Keeper, an odd-numbered ensemble (3 or 5 nodes), for replication coordination.
- ReplicatedMergeTree tables, so every table exists on more than one node.
- A Distributed table per sharded table, routing queries and writes across shards.
- Backups on a schedule, tested by restoring them.
- Monitoring, at minimum part counts and replication lag — see monitoring.
Shard to exceed one machine's capacity; replicate for availability and read throughput. The two are orthogonal and usually combined.
Bring Your Own Cloud#
BYOC runs ClickHouse Cloud's control plane against compute inside your own VPC. It exists for data residency and compliance requirements that rule out standard SaaS, and it is the middle path when self-hosting is operationally out of reach but data cannot leave your account.
The same engine, the same SQL. Storage and compute scale separately, and idle services scale to zero.
Related#
- Pricing — Basic, Scale, and Enterprise compared
- Install ClickHouse — run the open-source server
- Monitor a running server — what self-hosting requires you to watch