ClickHouse Cloud architecture is designed for real-time analytics without forcing teams to manage servers, disks, replicas, and rebalancing by hand. At its core, it separates management from execution, storage from compute, and, in advanced deployments, one workload’s compute from another. This guide explains the main components, how scaling works, and the practices that help teams run ClickHouse Cloud securely and cost-effectively.
ClickHouse Cloud is a managed, cloud-native version of ClickHouse where compute services run queries while durable shared object storage holds table data. The architecture uses SharedMergeTree over shared object storage, so computer replicas do not need to maintain independent full copies of data before they can serve workloads. That design supports faster scaling, simpler operations, and workload patterns that would be harder to manage in a traditional shared-nothing cluster. (clickhouse.com)
A useful architecture diagram would show users and applications connecting through a service endpoint, then routing into one or more compute replicas. Beneath those replicas, the diagram would place shared object storage as the persistent data layer, with metadata coordination through ClickHouse Keeper or the cloud metadata layer. Around the service, the diagram would show observability, security controls, scaling automation, and management APIs.
The control plane is the management layer. It handles orchestration tasks such as provisioning services, applying upgrades, scaling resources, enforcing policies, collecting platform telemetry, and exposing console or API workflows. In BYOC deployments, ClickHouse describes the control plane as ClickHouse-managed and responsible for orchestration, scaling, upgrades, monitoring, and billing, while not touching query data. (clickhouse.com)
The data plane is where customer workloads actually run. It includes the ClickHouse servers, compute resources, object storage, backups, service networking, and metrics that support query processing and storage. In BYOC, the data plane runs inside the customer’s cloud project or account boundary, while in standard ClickHouse Cloud the service is managed by ClickHouse in the selected cloud environment. (clickhouse.com)
The distinction matters because it clarifies both responsibility and risk. The control plane changes and manages the service; the data plane executes queries and stores data. A secure architecture minimizes unnecessary access between the two while still allowing automation, upgrades, monitoring, and support operations to work.
In ClickHouse Cloud, storage lives in object storage, while compute runs on CPU and memory resources called services. SharedMergeTree coordinates table data in shared storage through metadata, so adding or replacing compute nodes does not require copying a full local dataset onto each node first. (clickhouse.com)
This separation has several practical implications:
The tradeoff is that object storage has different latency characteristics than local disk. ClickHouse Cloud addresses this with caching layers, including local and distributed caching approaches, but teams should still benchmark cold and warm query paths for critical workloads. (clickhouse.com)
Vertical scaling increases the size of each replica, typically giving a service more CPU and memory per node. ClickHouse Cloud supports vertical autoscaling on Scale and Enterprise services based on CPU and memory usage, with administrators setting minimum and maximum sizes. This is often the first option to consider when queries need more memory, joins are heavy, or resource contention is the likely bottleneck. (clickhouse.com)
Horizontal scaling adds more replicas. It is useful when the workload is driven by concurrent queries, dashboard traffic, or write throughput that benefits from spreading independent work across more compute nodes. Administrators can change replica count through the console, API, or tooling, and official guidance notes that replica count is the horizontal scaling dimension while memory bounds control vertical scaling. (clickhouse.com)
Scaling checklist:
Traditional self-managed ClickHouse deployments often use shards to split data across nodes and replicas to provide redundancy and read throughput. ClickHouse Cloud changes that model because SharedMergeTree stores data once in shared object storage and exposes it to stateless compute replicas. Official training material describes data-level replication and sharding in ClickHouse Cloud as being replaced by SharedMergeTree’s compute-storage separation. (learn.clickhouse.com)
Replication still exists conceptually at the service level: multiple compute replicas can run in parallel for availability and throughput. Instead of each replica owning a full independent disk copy, replicas coordinate through shared metadata and shared storage. The benefit is less data duplication, simpler scaling, and fewer operational tasks around rebalancing.
Sharding strategy therefore shifts from “split every table across fixed nodes” to “design data layout, partitions, primary keys, and workloads so shared storage plus scalable compute can serve the workload.” For very large or specialized patterns, teams should still validate schema design and query distribution, but they avoid much of the manual shard management common in self-managed clusters.
ClickHouse Cloud supports multiple customers by separating services, access boundaries, and resource controls. Each customer organization manages its own users, roles, services, and network access. In BYOC, the separation is even more explicit: the data plane runs in the customer’s cloud account or project, while the ClickHouse-managed control plane operates separately. (clickhouse.com)
Security isolation is not just about identity. It also involves service-level compute boundaries, network restrictions, private connectivity options, encryption, and operational controls. For workload isolation within a customer environment, warehouses can provide compute-compute separation, allowing separate services and endpoints to share the same data while dedicating compute to reads, writes, dashboards, or batch analytics. (clickhouse.com)
Access control in ClickHouse Cloud is managed in two places: console access for the cloud organization and database access through database users and roles. ClickHouse supports RBAC-style entities such as users, roles, row policies, settings profiles, and quotas, and official learning material distinguishes console users from database users. (learn.clickhouse.com)
Security checklist:
Data protection should cover encryption in transit, encryption at rest through the underlying cloud infrastructure, managed backups, and controlled administrative access. For BYOC, customers also retain responsibilities for controls inside their own cloud environment, including customer-managed users, network security reviews, and incident response processes. (clickhouse.com)
Good operations depend on metrics, logs, and alerts. ClickHouse Cloud includes console monitoring dashboards, and recent platform updates added more health-oriented views for administrators. BYOC deployments on Google Cloud include a Prometheus, Grafana, and AlertManager monitoring stack, and ClickHouse tooling can expose Prometheus metrics for service-level investigation. (clickhouse.com)
Operationally, teams should monitor query latency, failed queries, memory use, CPU pressure, merges, ingestion lag, and replica health. Query logs are especially valuable because they show duration, memory consumption, user, query pattern, and failure context. Alerts should be tied to user impact, such as sustained latency breaches or ingestion delays, not only raw resource spikes.
Cost optimization starts with matching compute to workload shape. ClickHouse notes that Cloud can scale compute separately from storage, scale unused resources down, and use autoscaling limits to prevent unexpected bills. Auto-idling or wake-up behavior can reduce spend for quiet services where latency after idle is acceptable. (clickhouse.com)
Practical operating checklist:
The best ClickHouse Cloud architecture is not just “bigger compute.” It is a balanced design where storage, compute, security, observability, and cost controls reinforce each other. Start with the managed defaults, measure real workloads, and adjust scaling, isolation, and governance as usage becomes clearer.
Diacto specializes in leveraging ClickHouse to transform data processing capabilities with unparalleled speed and efficiency. As a performance-focused partner, Diacto offers expert consulting to ensure seamless integration and optimization of ClickHouse environments, empowering businesses to harness real-time insights.
Our core ClickHouse service offerings include:
By developing custom data architecture designs and ETL pipelines, Diacto helps teams fully exploit ClickHouse’s capabilities for predictive analytics and strategic planning.
