ClickHouse Cloud is the fully managed ClickHouse service operated by ClickHouse Inc., available on AWS, GCP, and Azure. It handles provisioning, upgrades, backups, replication, and scaling. The SQL interface and query semantics are the same as open-source ClickHouse, but the underlying storage and compute architecture diverges in ways that affect how you design schemas and operate the service. Understanding those differences before you commit to the managed path is worth the time.
SharedMergeTree: The Architectural Foundation
The most consequential technical difference between ClickHouse Cloud and self-managed ClickHouse is the table engine. Self-managed clusters use ReplicatedMergeTree, which replicates data across nodes using ClickHouse Keeper (or ZooKeeper) for coordination. Each node stores its own copy of the data on local disk. ClickHouse Cloud uses SharedMergeTree, a proprietary engine that replaces that model entirely.
With SharedMergeTree, all durable data lives in object storage (S3 on AWS, GCS on GCP, Blob Storage on Azure). Compute nodes are stateless; local disks are used only for ephemeral caches. Replication becomes a matter of metadata coordination rather than copying raw part files between nodes. ClickHouse Keeper still handles coordination and metadata storage, but there's no data duplication across replicas at the storage layer - all compute instances read from and write to the same shared object store.
This architecture enables two things that ReplicatedMergeTree cannot do cleanly. First, you can scale read replicas independently of write throughput without repartitioning or resharding. Adding a new compute node doesn't require moving data; it just starts serving queries against object storage with a warm local cache. Second, a single SharedMergeTree table can have hundreds of replicas, whereas ReplicatedMergeTree clusters are typically limited by the coordination overhead of maintaining consistent part metadata across many nodes. There is no sharding requirement because the storage layer is the object store, not a fixed set of disks attached to specific servers.
The trade-off is latency. Object storage has significantly higher baseline latency than local NVMe. ClickHouse Cloud addresses this through aggressive read-ahead, multi-threaded I/O, and a tiered local disk cache. For analytical workloads scanning large volumes of columnar data, the throughput characteristics are acceptable. For point lookups or workloads expecting single-digit millisecond response times, the cache miss penalty is real and the architecture is not a good fit regardless of cluster size.
ClickPipes: Managed Data Ingestion
ClickPipes is ClickHouse Cloud's managed ingestion service. It establishes and maintains pipelines from external sources into Cloud services without requiring you to run your own connectors, consumers, or CDC infrastructure.
For streaming sources, ClickPipes supports Apache Kafka (and Kafka-compatible systems including Confluent Cloud, Redpanda, AWS MSK, Azure Event Hubs, and WarpStream), plus Amazon Kinesis. For object storage, it pulls from Amazon S3, Google Cloud Storage, Azure Blob Storage, and DigitalOcean Spaces. Database sources use change-data-capture: PostgreSQL CDC is stable and generally available. MySQL CDC entered public beta in July 2025 and remains in public beta as of early 2026. The PostgreSQL CDC support came from ClickHouse's acquisition of PeerDB in 2024 and is based on logical replication slots.
The important operational point is that ClickPipes is a Cloud-only feature, and it replaces certain self-managed patterns that don't work in Cloud. Specifically, the Kafka table engine is not supported in ClickHouse Cloud — ClickHouse's documentation explicitly recommends ClickPipes or Kafka Connect as the alternatives for Kafka ingestion. If your current self-managed setup relies on Kafka table engines with materialized views for streaming ETL, you'll need to replicate that logic using ClickPipes or an external Kafka Connect deployment targeting the ClickHouse HTTP interface.
ClickPipes billing is separate from compute: streaming connectors charge per GB ingested plus compute units for the ingestion process (note that CDC connectors such as PostgreSQL and MySQL carry significantly higher per-GB rates than Kafka streaming connectors). Object storage connectors incur compute costs only. For high-throughput streaming workloads, the per-GB ingestion cost can become meaningful at scale.
Service Tiers and Operational Features
ClickHouse Cloud organizes services into three tiers: Basic, Scale, and Enterprise.
Basic is a single-replica, fixed-size service (8–12 GiB RAM) intended for development or departmental workloads with no strict availability requirements. It cannot autoscale and storage is capped at 1 TB, making it unsuitable for production workloads with variable load or larger datasets. Scale is the production tier: it supports multiple compute replicas sharing common object storage, horizontal and vertical autoscaling, and private networking. Enterprise adds compliance features, customer-managed encryption keys, hardware-level control, and advanced disaster recovery options.
Autoscaling and Service Pausing
Autoscaling in the Scale tier adjusts both vertical size (CPU/memory per node) and the number of replicas based on sustained CPU and memory pressure. The system reacts to observed resource utilization over a window, not instantaneously - so a spike that resolves in seconds may not trigger a scale event, but sustained elevated load will cause the service to grow. You can configure minimum and maximum boundaries to constrain cost and ensure a floor of resources. Scaling down happens more conservatively than scaling up to avoid thrashing under variable load.
Service pausing is a distinct feature: you can fully pause a Cloud service, stopping all compute billing while retaining data in object storage. Storage costs continue but compute drops to zero. This is genuinely useful for development environments, staging clusters, or services that run batch jobs on a schedule. Paused services typically take up to a minute or more to resume depending on service size, so this is not a tool for handling intermittent production traffic — it's for environments that are idle for hours at a time.
Private networking is available in the Scale and Enterprise tiers via AWS PrivateLink, GCP Private Service Connect, and Azure Private Link. Automated backups run daily with configurable retention; manual backups can also be triggered on demand.
When to Use Cloud vs. Self-Managed
ClickHouse Cloud removes substantial operational burden: no ZooKeeper or Keeper cluster to operate, no rolling upgrade procedures, no disk capacity planning across nodes, no manual replication topology management. For teams without dedicated infrastructure engineers or for workloads where the operational investment in self-managed ClickHouse isn't justified, Cloud is the right choice.
The honest limitations are cost predictability, feature parity, and portability. Cloud pricing changed in January 2025 and introduced egress fees, which makes migrating data out of Cloud expensive at scale. The pricing model separates compute and backup storage costs, and compute prices vary by tier and region. Self-managed ClickHouse on appropriately sized instances with S3-backed storage is consistently cheaper at high throughput volumes, though the gap narrows when you factor in engineering time.
Feature parity issues are real but mostly bounded. SharedMergeTree is proprietary and available only in Cloud - there's no path to run it yourself. The Kafka table engine is unavailable in Cloud. Some settings that are tunable in self-managed deployments are not exposed in Cloud. If your schema design relies on specific MergeTree variants or you need fine-grained control over merge settings, background job concurrency, or query priority, self-managed gives you more control surface.
Portability deserves attention before you commit. Your data is in object storage in ClickHouse's account, not yours. Migrating out requires either native replication tools or data export over the network - and with egress fees now in the pricing model, the cost of leaving is non-trivial at terabyte scale. If data sovereignty or migration flexibility is a requirement, factor that into the evaluation. That said, for most analytical workloads that ClickHouse is a good fit for, Cloud's defaults and autoscaling behavior will get you to production faster than standing up and tuning your own cluster.
