Since launching BYOC on AWS, we've seen organizations adopt it because they want the operational simplicity of a fully managed ClickHouse service, but they need their data to stay inside their own cloud account. With today's announcement, Google Cloud users can now get exactly that : no waitlist, no private preview access request.
What is BYOC? #
BYOC splits the control plane and data plane into separate VPCs."
- ClickHouse-managed control plane: Runs in ClickHouse's own VPC. Handles orchestration, scaling, upgrades, monitoring, and billing. It never touches your query data.
- Your data plane: Runs entirely inside your Google Cloud project. Your GKE cluster, ClickHouse servers, object storage (Google Cloud Storage), backups, and metrics all live within your account boundary.
The control plane communicates with your environment over a Tailscale zero-trust tunnel - outbound-only, encrypted, and scoped to orchestration traffic only. ClickHouse engineers with support access are restricted to system tables, with time-bound and audited sessions.
The result: you get a fully managed service without giving up data residency.
Why Google Cloud? #
Google Cloud is home to a significant share of enterprise data infrastructure. Organizations running BigQuery, Dataflow, and Pub/Sub pipelines naturally want their high-performance OLAP layer in the same environment - with the same IAM primitives, the same VPC controls, and the same compliance perimeter.
BYOC on Google Cloud makes ClickHouse native to that environment. Your service runs on GKE, stores data and backups in your GCS buckets, and connects to the rest of your Google Cloud workloads over private networking - no data crosses account or project boundaries.
ClickHouse BYOC is already available across all public ClickHouse Cloud Google regions. Over time we will expand support to additional Google Cloud regions.
Initial Set up #
Onboarding uses a three-step Terraform-based setup:
1. Account setup: Run a Terraform module that creates the IAM roles and trust permissions needed for the BYOC controller to manage infrastructure in your Google Cloud project. We follow least-privilege principles - the controller gets only what it needs to provision and maintain the cluster.
2. Infrastructure provisioning: In the ClickHouse Cloud console, select your Google Cloud region, configure your VPC CIDR range, and align availability zones. We recommend a dedicated Google Cloud project for BYOC - this gives you clean cost attribution and a clear resource isolation boundary.
3. Service creation: Specify a service name, select your BYOC environment and region, choose CPU/memory allocation, and configure replica count for high availability. Your GKE cluster, ClickHouse nodes, and monitoring stack are provisioned automatically.
If you have custom networking requirements or want to integrate with an existing VPC, reach out to ClickHouse Support - we support customized onboarding for those configurations.
What's Included #
BYOC on Google Cloud ships with the full set of capabilities you need to run production ClickHouse workloads:
- SharedMergeTree for efficient distributed storage
- Managed backups and restore : stored in your GCS buckets, never leaving your project
- Vertical and horizontal scaling : adjust replica count and node size per workload
- Auto Idling / Wake up : automatically idle services during quiet periods to reduce costs
- Compute-compute separation via Warehouses - isolate different query workloads across dedicated compute groups
- Prometheus / Grafana / AlertManager monitoring stack
- Datadog integration for teams with centralized observability pipelines
- VPC Peering and Private Service Connect for enterprise network configurations
Upgrades and Maintenance #
ClickHouse handles both ClickHouse database upgrades and supporting infrastructure upgrades (Kubernetes operator, Istio, monitoring components) in the background via ArgoCD. Database upgrades follow a make-before-break strategy: updated replicas are added before old ones are removed, minimizing disruption. You can select Fast, Regular, or Slow release channels, with upgrades aligned to your configured maintenance window.
