Most ClickHouse® deployment guides start with where the process runs: a VM, a Docker host, a Kubernetes operator, a cloud marketplace image, or a managed service. That list is useful. It is also the second decision.
The first decision is the operating model. Who owns the environment, who responds when production needs capacity, and who is allowed to change the cluster.
This is the comparison we use with teams that are already in production, or about to be. If you want the self-hosted vs managed argument in isolation, read self-hosted vs managed ClickHouse. If you want the replica-level runbook, read ClickHouse cluster operations. For the installer-level walkthrough of VMs, Docker, and Kubernetes, the deployment options guide still applies.
Deployment model vs operating model
Deployment model answers: where does the binary run?
| Where it runs | What you get | What you still do |
|---|---|---|
Laptop / clickhouse-local / chDB | Ad-hoc analysis, embedded OLAP | Not production |
| Single VM or bare metal | Full config.xml, local NVMe | Everything, including the day the disk fills |
| Docker Compose | Repeatable dev clusters | Fine for local. Dangerous as "the prod topology" |
| Kubernetes operator (Altinity or ClickHouse) | StatefulSets, PVCs, rolling restarts from YAML | Day-2: storage classes, pod disruption, Keeper as its own StatefulSet, no online reshard |
| Cloud marketplace AMI | Faster first boot | Same ops as a VM you installed yourself |
| Hosted database (ClickHouse Cloud, Altinity.Cloud, Aiven) | Provider-owned nodes | App layer, APIs, a lot of sizing |
| Tinybird Cloud | Provider-owned ClickHouse plus ingestion and APIs | Data model and deploys. Replica topology only on dedicated |
The Kubernetes operator is the usual "we have control" move. It automates pod lifecycle. It does not take the pager. Adding replicas still means PVCs, Keeper registration, waiting for ReplicatedMergeTree to fetch parts, then updating services so clients do not hit a half-synced pod. Horizontal pod autoscaling on CPU is a poor fit: ClickHouse scale-out is topology, not stateless replica count.
Operating model answers: when it is 2:07 a.m. and production needs capacity, who owns the environment, the incident, and the change?
The four production operating models
| Model | You own | The provider owns | You decide at production time |
|---|---|---|---|
| 1. Self-managed ClickHouse | Environment, incident response, cluster change, ingestion, APIs | Nothing | Everything, if someone is awake |
| 2. Conventional managed ClickHouse | App layer, APIs, sizing and upgrade planning | Nodes, backups, most version maintenance | Cluster size and settings, often through a ticket |
| 3. Tinybird shared infrastructure | Data model, Pipes, endpoints, deploys | Cluster, scaling, upgrades, ingestion fabric | Workspace resources, not replica topology |
| 4. Tinybird dedicated + Cluster Management | Replica count, SKU, read/write/copy weights, data layer as code | Provisioning, replication, platform operations | Selected production control. Tinybird executes it. |
Same engine in all four. Different pager. Tinybird Self-Managed is model 1 with Tinybird's developer tooling: you keep pipes and the CLI, you take back the environment.
Model 1: Self-managed ClickHouse
You install ClickHouse and Keeper on infrastructure you control. On-prem, cloud VMs, or Kubernetes. This is the default path for teams that already have a data platform group.
Environment. Yours. VPCs, disks, object storage, load balancers, IAM, the three-node Keeper quorum on separate machines.
Operational response. Yours. Merge storms, replica lag, Keeper session expiry, disk saturation, Too many parts. What I learned operating ClickHouse is the catalog.
Production change. Yours. Adding a replica means provisioning, attaching storage, registering in Keeper, waiting for replication (queue_size and absolute_delay at zero), then advertising the node in remote_servers. Removing a replica means draining traffic, then SYSTEM DROP REPLICA so Keeper is not left with ghost metadata. There is no built-in online reshard. New shards get new writes. Old partitions stay until you move them with INSERT SELECT or a migration tool.
Choose this when policy, hardware, or an existing ClickHouse practice makes operating the database a core competency. Do not choose it because the open source binary is free. The binary is free. The shift is not.
BYOC (ClickHouse Cloud BYOC, Altinity in your VPC) is not this model. The vendor still operates ClickHouse inside your account. You own networking and IAM. See ClickHouse BYOC vs fully managed.
Model 2: Conventional managed ClickHouse
A vendor runs the database service. ClickHouse Cloud is the reference product. Altinity.Cloud and Aiven sit nearby. You get a hosted cluster, client access, and much less node babysitting.
ClickHouse Cloud uses SharedMergeTree and object storage. Compute can scale without copying parts between local disks. Direct clients, ClickPipes, per-minute compute, pause-to-save on idle services. You still build ingestion beyond ClickPipes, the API layer, auth, and git workflow. Basic cannot autoscale. Scale and Enterprise can.
Altinity.Cloud is open source ClickHouse on dedicated Kubernetes, often with the ability to add shards and replicas yourself, plus 24/7 specialist support. Closest managed analog to "I want the OSS cluster, not a fork, not an API product."
Aiven is multi-cloud database hosting with the rest of their catalog.
Environment. The provider's, or BYOC in your account.
Operational response. Split. The vendor handles host failure. You still handle query load, schema, and everything you built on top.
Production change. You request or click a resize. Timing depends on the vendor's control plane and your change process.
Choose this when you want a database, not a product platform, and you have people who will do the rest.
Model 3: Tinybird shared infrastructure
Tinybird shared plans (Free, Developer, and the non-dedicated paid tiers) put your workspace on shared ClickHouse infrastructure that Tinybird sizes and operates.
You define datasources and pipes. You publish endpoints. You deploy with git or npx tinybird. You do not pick replica SKUs. Plans include automatic scaling up to 2x baseline vCPU, consumed from the monthly vCPU-hour allowance.
Environment. Tinybird's.
Operational response. Tinybird's.
Production change. You ship SQL and schema. You do not rebalance replicas. Capacity is a platform concern, not a 2 a.m. runbook on your side.
This is the fastest path from event to API. Resend, Dub, and Factorial-style workloads start here: user-facing analytics, sub-100 ms endpoints, no ClickHouse platform hire. Tinybird's free plan has no time limit: 10 GB storage, unlimited processing, 1,000 API requests/day.
Choose this when you are building product analytics and you do not need isolated hardware or replica-level control.
Model 4: Tinybird dedicated infrastructure with Cluster Management
Enterprise dedicated infrastructure gives you an isolated ClickHouse cluster. You are the only tenant on those replicas. Ingestion and queries run on hardware reserved for your organization, in your cloud and region (AWS or GCP).
Cluster Management is the production-control layer on that cluster, for eligible customers with self-serve replica management enabled.
Environment. Tinybird-operated, isolated to you.
Operational response. Tinybird operates the platform. You are not on the hook for Keeper, upgrades, or node repair. Compute-compute separation for populates still applies: heavy backfills can run on ephemeral replicas so they do not steal CPU from APIs.
Production change. You add or remove replicas and set weights. Tinybird provisions the replica, replicates the dataset, and applies traffic distribution. UI path: Settings → Plan & Billing → Manage Cluster. Same operations exist on the Organizations API (announced March 2026).
What you control:
- Replica SKU (for example
4-16) - Replica count
- Read weight: query traffic, 0-65535
- Write weight: Events API and Kafka ingest, 0-65535
- Copy-job weight: default
1on every replica
What you do not operate:
- Provisioning and replacement
- Data replication onto a new replica
- ClickHouse upgrades
- The ingestion fabric, API hosting, and git workflow around the cluster
Adding or removing replicas changes the Dedicated ClickHouse cluster SKU immediately. This is a manual capacity decision, not an autoscale policy. Confirm current overlap and duration against your contract before you put it in a runbook.
Choose this when the workload is customer-facing or otherwise isolated, you need to add capacity without a ticket, and you do not want to staff a ClickHouse platform team to get that control.
Tinybird across the matrix
Tinybird is not "ClickHouse Cloud with extra YAML." It is ClickHouse plus the product layer. The comparison against a hosted database is Tinybird vs ClickHouse and Tinybird vs ClickHouse Cloud. The short version:
| Layer | Self-managed / conventional managed | Tinybird |
|---|---|---|
| Engine | ClickHouse OSS or Cloud SharedMergeTree | Tinybird fork of ClickHouse, contributions upstream |
| Ingest | Kafka engine, ClickPipes, or something you wrote | Events API, managed Kafka, S3, GCS |
| Serve | Your API, pooling, auth | Pipes as HTTP, tokens and JWTs, OpenAPI |
| Iterate | Hope staging looks like prod | Branches per PR, local npx tinybird dev |
| Observe | Roll your own on system tables | Service datasources, endpoint metrics |
| Isolate jobs | Resize the cluster or pray | Ephemeral populate replicas |
| Replica topology | remote_servers + Keeper, or vendor console | Cluster Management on dedicated only |
You can start shared and move to dedicated later. Workspaces and the data-as-code workflow carry across. Dedicated is an infrastructure change, not a rewrite of pipes.
You can also run Tinybird Self-Managed when the CISO says the data plane stays in your account. That is model 1 for operations and model 3/4 for developer workflow.
Compliance (SOC 2 Type II, HIPAA, GDPR, SSO/SAML, RBAC) is an Enterprise gate on whether you can pick Tinybird at all. It does not replace the shared vs dedicated choice.
How the 2:07 a.m. alert plays in each model
Production needs more query capacity.
| Model | What happens |
|---|---|
| Self-managed | Page the person who knows the cluster. Provision, wait for replication, edit remote_servers, hope the runbook is current. Historical shards do not rebalance themselves. |
| Conventional managed | Open the vendor console or file a ticket. ClickHouse Cloud may add compute against object storage. Your API layer is still yours if it melts. Basic cannot scale. |
| Tinybird shared | Tinybird operates capacity. You watch endpoint latency. No replica topology to change. |
| Tinybird dedicated | Change replica count or weights in Cluster Management. Tinybird executes. |
That last line is the campaign claim in operational terms: you decide, Tinybird operates. It only applies to dedicated infrastructure where Cluster Management is enabled. Do not promise it on shared plans.
A practical selection rule
- If a regulator or a CISO says the database cannot leave your account, start with self-managed or Tinybird Self-Managed. BYOC is the conversation if you want a vendor inside your VPC.
- If you want a hosted ClickHouse database and you will build the product layer, conventional managed is coherent.
- If you want to ship APIs over events this week, start on Tinybird shared.
- If shared is the right workflow but you need isolation, reserved capacity, and replica-level control, move to dedicated and turn on Cluster Management.
- Do not pick Kubernetes because it looks like control. The operator automates pods. It does not take the pager.
Frequently Asked Questions (FAQs)
Is Tinybird dedicated the same as ClickHouse Cloud?
No. Both can give you an isolated ClickHouse cluster. Tinybird dedicated also includes the product layer (ingestion, SQL-to-API, branches, SDKs) and Cluster Management for replica topology. ClickHouse Cloud gives you a managed database with more setting-level exposure, SharedMergeTree, and direct clients. You still build the API.
Can I start shared and move to dedicated later?
Yes. Workspaces and the data-as-code workflow carry across. Dedicated is an infrastructure change, not a rewrite of your pipes. Cluster Management is a dedicated-only surface.
Does "operating model" mean the same thing as "deployment model"?
People use both phrases for the same search. Deployment model usually means VMs vs containers vs managed. Operating model means who owns environment, incident, and change. Kubernetes is a deployment. Self-managed is an operating model that can run on Kubernetes.
What about Tinybird Self-Managed?
It is model 1 with Tinybird's developer tooling. You operate the environment, including Keeper and replicas. You keep datasources, pipes, and the CLI/SDK workflow. Choose it when you need the Tinybird data layer on infrastructure you run.
Where do SOC 2, HIPAA, and SSO show up in this matrix?
They are available on Tinybird Enterprise. They influence whether you can pick Tinybird. They do not replace the operating-model choice between shared and dedicated.
Is the Altinity Kubernetes operator "managed ClickHouse"?
No. The operator is automation for a cluster you still operate. Managed means someone else owns node failure, upgrades, and Keeper. If your SRE team runs the operator, you are in model 1.
Does ClickHouse Cloud pause pricing work for user-facing APIs?
Pause-to-zero compute helps intermittent analytics and dev services. Product APIs that must answer in milliseconds cannot pause. Always-on Scale/Enterprise is the relevant comparison, not the Basic six-hours-a-day calculator screenshot.