ClickHouse Cloud vs Self-Hosted

ClickHouse has won the real-time analytics tier. Once you’ve decided to use it (see our piece on when ClickHouse beats Postgres and Snowflake), the next question is where to run it: ClickHouse Cloud (the official managed service) or self-hosted (on Kubernetes, VMs, or bare metal).

Both work. The choice is dominated by your team’s ops capacity, your scale, and how much vendor-managed simplicity you want to pay for.

The thirty-second framing#

ClickHouse Cloud is ClickHouse Inc’s managed service — fully separated compute and storage, auto-scaling, no ops, predictable monthly bill. Runs on AWS, GCP, or Azure regions of your choosing.
Self-hosted ClickHouse is the open-source ClickHouse OSS, deployed on your own infrastructure. ClickHouse Keeper for coordination, multiple replicas for HA, your team operates everything.

Same query engine, same SQL, same wire protocol. Wildly different operational stories.

What’s actually different#

Dimension	ClickHouse Cloud	Self-Hosted ClickHouse
License	Commercial managed service	Apache 2.0
Compute / storage separation	Native (object storage backed)	Optional (shared-nothing default, S3-backed possible)
Auto-scaling	Yes (idle scale-to-zero on some tiers)	DIY (Kubernetes HPA, KEDA)
Backups	Automatic, point-in-time recovery	DIY (ClickHouse backups + object store)
Replication / HA	Managed	DIY (ReplicatedMergeTree + Keeper)
Pricing	Per-second compute + storage	Infrastructure cost only
Idle cost	Can scale to zero	You pay for nodes 24/7
Multi-region	Yes (paid feature)	DIY (cross-region replication)
Operational surface	Minimal	Real
Customization	Limited (no custom kernels, configs limited)	Full
Upgrades	Automatic	You schedule + test
Compliance	SOC 2, HIPAA-eligible, varies by region	Whatever you build on

Where ClickHouse Cloud wins#

Auto-scaling and idle economics. Cloud’s compute-storage separation means you can scale compute up for query bursts and down (sometimes to zero) when idle. Self-hosted means paying for whatever nodes you provisioned, idle or not. For variable workloads, this is a meaningful win.

Operational simplicity. No Keeper to manage. No replicated table coordination to debug. No backup scripts. No upgrade planning. For small teams without dedicated infra/DBA capacity, this is real value.

Backups and disaster recovery. Point-in-time recovery, automatic backups to object storage, cross-region replication options. Building this yourself isn’t hard but it’s not free.

Predictable pricing. Per-second compute + storage. Spend caps are configurable. You won’t get surprised by a $20k bill unless you actively misuse it.

Mature integrations. First-class connections from Tableau, dbt, Looker, Superset, Grafana. Self-hosted works with all the same tools but you handle the connection-string ops yourself.

Built-in observability. Cloud dashboard shows query performance, slow queries, resource usage. Self-hosted needs you to wire up Grafana + ClickHouse system tables yourself.

Where ClickHouse Cloud hurts:

Cost at scale. Above ~5TB stored / 100M queries/month, the per-second compute pricing starts adding up significantly vs amortized self-hosted.
Limited customization — can’t tune low-level kernel settings or run custom builds. Most teams don’t need this; some do.
Vendor lock-in to ClickHouse Inc. If their pricing model changes, you migrate.
Some advanced features (specific MergeTree engines, certain table functions) lag or are limited in Cloud.

Where Self-Hosted wins#

Cost at scale. A 3-node ClickHouse cluster on 2× owned/reserved EC2 m6g.4xlarge runs you ~$500-$1000/month all-in (EC2 + EBS). Equivalent Cloud capacity is meaningfully more. For workloads above ~10TB and millions of queries, self-hosted is dramatically cheaper.

Full control. Custom builds, custom table engines, specific kernel configurations, exotic deployment topologies — all yours. We’ve deployed ClickHouse with specific patches for clients with truly unusual workloads.

Air-gapped or on-prem. Some regulated workloads (defense, certain banking, certain healthcare) require infrastructure that never touches the public cloud or a third-party service. Self-hosted is the only path.

Bring-your-own compliance posture. You build the compliance story on your own infrastructure. For some compliance regimes (NRB in Nepal, certain government requirements), this is easier than vetting Cloud’s existing posture.

Same model as your other infra. If you already operate Postgres, Redis, Kafka, etc. on Kubernetes, ClickHouse fits the same pattern. One operational model.

Where Self-Hosted hurts:

Real ops surface. Keeper (or ZooKeeper for older versions), replication, backups, monitoring, capacity planning, upgrades. All on you.
Auto-scaling is harder. Adding/removing replicas mid-flight requires care; truly elastic compute requires the compute-storage separation you’d get for free in Cloud.
Lifecycle work: minor version upgrades quarterly, major version planning annually, schema migrations across replicas, broken-node recovery.
The learning curve. ClickHouse has its own concept of MergeTree variants, replication patterns, materialized views. Operators who haven’t worked with it before have a real ramp.

When we deploy which#

Default to ClickHouse Cloud if:

You’re standing up ClickHouse for the first time and want to move fast
Your team has no dedicated DBA / infrastructure ops capacity
Your workload is small-to-medium (under ~5TB hot data, predictable usage patterns)
Compliance posture is acceptable on Cloud
You don’t want to think about backups, replication, or upgrades

Default to Self-Hosted if:

You have existing platform team operating other stateful systems
Your scale is meaningful (10TB+ or millions of queries/day) and the cost math favors self-hosted
Air-gapped, on-prem, or strict data-residency requirements
You want truly minimal vendor relationship
You want to amortize across many workloads on shared infrastructure

Start with Cloud, plan to migrate is also a common path. Start fast with Cloud, get the system into production, then migrate to self-hosted later if cost or compliance pushes you that direction. Migration isn’t trivial but it’s tractable (export to S3, restore on self-hosted; cutover with downtime window).

The middle path: managed offerings beyond ClickHouse Cloud#

A few alternatives if neither pure Cloud nor pure self-hosted fits:

Aiven for ClickHouse — managed ClickHouse from a third-party. Less feature-complete than ClickHouse Cloud but a real option.
Altinity.Cloud — managed by Altinity (long-time ClickHouse experts). Strong for teams that want managed with more flexibility than ClickHouse Cloud allows.
Tinybird — ClickHouse-backed API layer for high-velocity analytics features. Different shape — you don’t operate ClickHouse directly, you use Tinybird’s API. Strong for user-facing analytics features in SaaS products.
PropelData — similar to Tinybird, ClickHouse-backed managed analytics platform.

These earn their keep when you want managed but ClickHouse Cloud doesn’t fit (price, features, region).

Self-hosted on Kubernetes vs VMs vs bare metal#

If you’re self-hosting:

Kubernetes with the Altinity Operator is the modern default. The operator handles a lot of the orchestration (replicas, Keeper, backups). Fits well into existing K8s platforms.

VMs (EC2, GCE) with manual config works for smaller deployments where K8s feels overkill. We’ve shipped this for clients with 1-3 nodes who didn’t want K8s overhead.

Bare metal for the truly large deployments where every dollar of cloud premium matters. Rare; usually only at huge scale.

We default to Kubernetes + Altinity Operator for new self-hosted deploys unless the client has a strong reason for something else.

What we deploy by default#

For typical client work:

Small platform (under 1TB hot, single team): ClickHouse Cloud Basic or Production tier. Get out of ops.
Mid platform (1-10TB, growing data team): Either — choose based on compliance and budget posture. We slightly default to Cloud here for ops simplicity.
Large platform (10TB+, mature team): Self-hosted on K8s with Altinity Operator. Cost wins.
Hospital / bank with data-residency requirements: Self-hosted on in-country cloud (NTC, World Link in Nepal; equivalents in other markets) or on the client’s existing on-prem infrastructure.
User-facing analytics in SaaS products: Tinybird if API-shaped, ClickHouse Cloud if SQL-shaped.

For our data engineering team’s typical deployments — Hospital Management Systems, banking analytics, supply chain dashboards — the split is roughly 60% self-hosted (due to data-residency requirements) and 40% Cloud (for teams without ops capacity).

The thing neither solves#

ClickHouse Cloud vs self-hosted is an ops choice, not a data-modeling choice. Both give you the same engine. The hard parts of building a real-time analytics platform — data modeling, materialized views, partitioning strategy, query optimization, change data capture from operational stores — are the same either way.

The teams that get the most value out of ClickHouse aren’t the ones obsessing over Cloud vs self-hosted. They’re the ones who designed the data model right, materialized the right aggregates, and instrumented their query patterns.

The pattern of patterns#

ClickHouse Cloud vs self-hosted is a real choice with real money on the line, but it’s mostly downstream of two things: your team’s ops capacity, and your scale. Pick the one that fits both, and move on to the harder problems (data modeling, query patterns, integration).

The migration path between the two is well-understood. Don’t agonize. Start with what fits today; revisit when the math changes.

The cluster you operate is the cluster you should pick. If you’re standing up real-time analytics and want a second pair of eyes on the deployment model, our data engineering team has shipped both Cloud and self-hosted in production. Tell us about the workload.