Self-hosted vs managed ClickHouse

It's 2:07 a.m. Production needs more capacity. Query latency is climbing. Ingest is backing up. The engine is still ClickHouse^®. The question is who gets paged, who can change the cluster, and how long that change takes.

Self-hosted vs managed ClickHouse is not a feature comparison. Both run the same SQL. The difference is the operating model: who owns the environment, who owns the operational response, and who executes the production change.

If you are choosing a ClickHouse operating model for production, start here. If you already know you need replica topology and workload distribution without running the platform, skip to cluster operations.

What you are actually choosing

A self-hosted cluster gives you the binary, the disks, and every knob in config.xml. A conventional managed service (ClickHouse Cloud, Altinity.Cloud, Aiven) gives you a hosted database. Tinybird gives you an isolated or shared ClickHouse cluster plus the ingestion, API, and git workflow around it.

Those are three different jobs.

The engine does not change. The pager does.

What self-hosting actually includes

Installing ClickHouse is the easy part. Javi Santana has operated petabyte-scale clusters at Tinybird since version 18.4. His summary still holds: setting up a cluster is easy. Keeping it running is the work.

A production self-hosted cluster is not one process. At minimum you need two ClickHouse nodes for high availability, a three-node ClickHouse Keeper (or ZooKeeper) ensemble for quorum, and a load balancer in front. Keeper must not share machines with the database. If the coordination layer sits on the same overloaded box as merges, tables go read-only and you spend the night in system.replicas.

Replication is a copy, not a pointer

Self-hosted production tables use ReplicatedMergeTree. Each replica stores its own copy of the data. Keeper coordinates the replication log: which parts exist, which merges to run, which replica is leader. Adding a replica means the new node creates the table with the correct Keeper path, fetches existing parts, and only then belongs in remote_servers. Advertise it to clients before queue_size and absolute_delay are at zero and you serve partial results.

Replication roughly doubles storage for a 2-replica layout and triples it for 3. A 300 TB table with 10 replicas is 3 PB of copies if you keep data local. That is why teams move to object storage and zero-copy replication, and why ClickHouse Inc. has been uneasy about the open source zero-copy path. Tinybird runs a modified version of it. ClickHouse Cloud avoids the copy problem with SharedMergeTree, which is not available in open source.

Inserts, merges, and the 2 a.m. failure mode

Every INSERT creates a part. Background merges compact parts so reads scan fewer files. If you insert faster than you merge, active part counts climb. Past parts_to_delay_insert (1000 per partition in recent versions) inserts slow down. Past parts_to_throw_insert (3000) inserts fail with Too many parts.

The cluster looks "up." Keeper is fine. The network is fine. system.merges shows the same entries for hours. system.replication_queue fills with MERGE_PARTS and GET_PART that never clear. A Keeper session expiry (is_readonly = 1, is_session_expired = 1) stops merge scheduling until the session is back. SYSTEM RESTART REPLICA is the usual recovery when the in-memory queue drifted from Keeper.

This is the work self-hosting buys you: batch size, partition keys, background_pool_size, compact parts on S3, a backpressure queue in front of inserts, and an on-call rotation that can read those system tables without a tutorial.

Upgrades are a protocol problem

ClickHouse ships stable packages roughly monthly. Upgrading a replicated cluster means adding a replica on the new version, watching logs, sending read traffic, then writes, then rolling the rest. The replication protocol has to stay backward compatible across mixed versions. Tinybird's first production upgrade took 3 hours after 2 weeks of preparation. Making upgrades a CI/CD non-event took years: mixed-version test clusters, daily replay of customer queries against the next version, and a rule not to use new SQL on a replica until the whole cluster is there.

You also own backups you have actually restored, disk vs object storage and S3 PUT costs, cache sizing, and DDL that must not run mid-upgrade.

Self-hosting is the right call when you have that muscle and a reason to use it. Strict data residency that a SaaS region cannot meet. An existing ClickHouse platform team. Hardware (local NVMe, specific CPU generations) a provider will not give you. Those are real constraints.

If the reason is "we want control," be precise about which control. Most teams want to decide replica count and workload placement. They do not want to own Keeper failover.

What conventional managed ClickHouse actually includes

Managed ClickHouse removes node provisioning, backups, and a large chunk of version maintenance. That is a real reduction in operational load. It is also a narrower product than people expect when they search "managed ClickHouse."

ClickHouse Cloud

ClickHouse Cloud is the official managed service from ClickHouse, Inc. Production clusters use SharedMergeTree: durable data lives in object storage (S3, GCS, or Azure Blob), compute nodes are largely stateless, local disks are cache. Adding a compute node does not copy parts between replicas. Metadata still goes through Keeper, which the provider operates.

You get a hosted database, SQL console, ClickPipes for Kafka and some CDC sources, Terraform, and direct clients (native, HTTP, JDBC). Autoscaling and multi-replica HA sit on Scale and Enterprise tiers, not Basic. Compute is metered per minute. You can pause a service and stop compute billing. Always-on user-facing APIs do not pause, so the idle-discount story does not apply to the workloads Tinybird is built for.

You still pick service size and scaling policy, plan upgrades on Enterprise, and build the HTTP ingestion path, auth, API layer, and CI/CD yourself. Query lambdas exist. They are not a production API platform.

Altinity.Cloud and Aiven

Altinity.Cloud is hosted open source ClickHouse, often in a dedicated Kubernetes environment, with 24/7 ClickHouse expert support. You can add shards and replicas on running clusters. You still operate the database as a database: DDL, schema, ingestion, APIs. Altinity also maintains the Kubernetes operator many self-hosted teams use.

Aiven for ClickHouse is a multi-cloud database alongside Postgres and Kafka. Unified billing, VPC peering, automated backups. Same shape: hosted engine, you build the product layer.

What you still own on a hosted database

• Cluster size and when to change it
• Insert batching and table design (managed does not fix Too many parts)
• The API, auth, and connection pooling in front of SQL
• Preview environments and schema migration
• On-call for your queries even when the vendor owns the VMs

For a feature-level comparison of Tinybird and ClickHouse Cloud, see Tinybird vs ClickHouse Cloud. For the broader market, see managed ClickHouse options. For VMs vs Docker vs Kubernetes, use the deployment models guide. That guide answers where it runs. This one answers who runs it when it breaks.

Conventional managed is the right call when your team already has ClickHouse expertise, wants direct client access and setting-level control, and is willing to own everything above the database.

The cost that does not show up on the invoice

Instance hours are the visible line. The expensive line is engineering time.

Self-hosted TCO is hardware plus Keeper plus load balancers plus backup storage plus people. A small production cluster still needs someone who can read system.query_log and system.parts. Past ~20k rows/s with people shipping schema changes, Javi's rule of thumb is a full-time person. Hardware can look 3-4x worse if nobody is watching partition keys and insert size. Audiense estimated Tinybird saved hiring 3-5 engineers.

ClickHouse Cloud TCO is per-minute compute, compressed storage, backups billed like data, egress, and ClickPipes. Basic examples in the public calculator sit around tens to low hundreds of dollars if you pause. Always-on Scale with two small replicas starts near $499/month before you have built an API. Storage and extra backups move the number fast. See the Tinybird vs ClickHouse Cloud cost comparison for worked examples.

Tinybird TCO is a plan (Free, Developer, Enterprise) with vCPU-hour and storage included, plus dedicated SKUs if you isolate the cluster. 93% of non-enterprise customers pay less than $100/month. The median paid workspace is under $10/month. That is not an enterprise dedicated cluster. It is the shape of "we shipped an API and did not hire a DBA."

If you are staffing a new ClickHouse platform team to avoid a managed bill, run the fully loaded number: upgrades, incidents, and the year you spend making upgrades boring. Not just VMs.

Tinybird: not a hosted database with a nicer UI

Tinybird is managed ClickHouse plus the layer most teams build anyway. The team maintains its own fork and contributes upstream (joins, parallel replicas, backup engine). A small set of niche engines and functions is disabled on purpose.

What you get that a hosted database does not include

Ingestion. POST JSON to the Events API at 1K+ requests/second and 20 MB/s. Data is queryable in seconds. Kafka, S3, and GCS connectors are managed. You do not run the Kafka table engine inside the same process that serves user queries unless you choose to.

Queries as APIs. A Pipe is SQL with templated parameters. Publish it and you get an HTTP endpoint, tokens or JWTs, rate limits, and OpenAPI. You do not put Lambda plus API Gateway plus ElastiCache in front of clickhouse-client.

Data as code. Datasources, pipes, tests, and tokens live in git as TypeScript (@tinybirdco/sdk) or .datasource / .pipe files. npx tinybird deploy is the production path. Branches give you a preview workspace per PR.

Observability. Service datasources log every API request and ingest. You query your own platform the same way you query events.

Populate isolation. Compute-compute separation spins ephemeral replicas for heavy backfills so a populate does not steal CPU from user-facing queries. That is the same idea as a write replica, automated.

Shared vs dedicated vs Self-Managed

Shared infrastructure (Free, Developer, non-dedicated paid): Tinybird sizes and operates the cluster. You ship SQL. You do not pick replica SKUs. Automatic scaling up to 2x baseline vCPU is a plan feature, not a 2 a.m. replica runbook.

Dedicated infrastructure (Enterprise): you are the only tenant on those ClickHouse replicas. Isolation for ingest and query. Vertical resize from the UI. Cluster Management (eligible clusters) lets you add or remove replicas and set read, write, and copy-job weights (0-65535, weighted round-robin) from Settings → Plan & Billing → Manage Cluster or the Organizations API. Tinybird provisions in your cloud and region (AWS or GCP), replicates the dataset, and applies traffic. Guardrails refuse a config with no reads or no writes. API mutations send old_weights so two changes cannot clobber each other.

This is not autoscaling. You decide. Tinybird executes and operates the platform. Adding a replica changes dedicated SKU billing. Confirm current overlap and timing against your contract before you automate it.

Self-Managed: same developer workflow, you operate the environment. Choose it when policy says the database cannot leave your account.

What production looks like on Tinybird

Canva processes 3.6 PB per month at 54 ms p99. Resend processes 100 TB per month at 62 ms p90 without leaning on cache. Shared infrastructure typically lands 20+ MB/s writes and 1K+ QPS with sub-50 ms p95 when the schema is sane. Enterprise dedicated is the path when you need isolation and replica-level control.

You still design tables. A bad partition key still produces too many parts. Tinybird does not make ClickHouse SQL optional. It makes Keeper, upgrades, and the API layer not your on-call problem.

How the 2:07 a.m. alert plays

Production needs more query capacity. Ingest is fine. Queries are not.

Self-hosted. Page the person with cloud credentials and Keeper access. Launch a node that matches the SKU. Create replicated tables. Wait until system.replicas shows queue_size and absolute_delay at zero. Add the host to remote_servers on every node. Shift the load balancer. Watch p99. If this is the first time in six months, budget longer than the incident. There is no online reshard if you guessed shard count wrong. Historical data stays put until you INSERT SELECT it.

Conventional managed. Open the vendor console or file a ticket. ClickHouse Cloud can add compute against shared object storage without copying parts. You still own the API pool, retries, and whatever is melting in application code. Basic tier cannot scale. Scale/Enterprise can, on their policy, on their clock.

Tinybird shared. Watch endpoint latency in workspace observability. Tinybird operates capacity. There is no replica topology for you to change.

Tinybird dedicated, Cluster Management enabled. Raise read weights or add a replica. Tinybird provisions, replicates, applies weights. You are not editing remote_servers or draining Keeper metadata by hand.

The useful test is that last row. When production needs more capacity, who can make the change, and who is still awake after it ships?

Frequently Asked Questions (FAQs)

Is managed ClickHouse the same as Tinybird?

No. Managed ClickHouse is a hosted database: nodes, backups, a SQL console, maybe connectors. Tinybird is a data platform on ClickHouse: Events API, Kafka/S3/GCS connectors, SQL Pipes published as HTTP endpoints, branches, TypeScript and Python SDKs, and service-level observability. Dedicated customers can also manage replica topology. Shared-plan customers cannot.

Can I self-host Tinybird?

Yes. Tinybird Self-Managed runs on your infrastructure. You keep datasources, pipes, and the CLI/SDK workflow. You take back platform operations, including Keeper and replica topology. Choose it when policy requires you to operate the environment.

Do I lose ClickHouse if I pick a managed service?

No. You are still running ClickHouse SQL. Tinybird maintains a fork and contributes upstream. A small set of niche engines and functions is disabled for performance and security. ClickHouse Cloud exposes more settings and direct write clients. Tinybird exposes read access over the HTTP interface and pushes writes through its ingestion paths.

When is self-hosted cheaper?

When you already have the people, the on-call rotation, and utilization high enough that instance cost dominates. Replication multiplies storage (2x or 3x copies on ReplicatedMergeTree). Keeper is three extra nodes. If you are hiring a platform team to avoid a managed bill, include salaries, upgrades, and incidents. Hardware-only comparisons lie.

What can I control on Tinybird dedicated infrastructure?

Replica SKU, replica count, and per-replica weights for reads (query traffic), writes (Events API and Kafka), and copy jobs (default 1 on every replica). Tinybird operates provisioning, replication, upgrades, and the platform around the cluster. Cluster Management is available where self-serve replica management is enabled. Shared plans do not expose this surface.

Does ClickHouse Cloud's SharedMergeTree make self-hosting obsolete?

It makes copying parts between local disks obsolete for people who are fine on ClickHouse Cloud's engine and object-storage latency profile. Self-hosted OSS still uses ReplicatedMergeTree. If you need local NVMe tail latency, specific hardware, or data that cannot sit in the vendor's object store, you still self-host. Tinybird dedicated is the middle: isolated compute, Tinybird-operated storage and platform, replica control without Keeper on-call.

Who handles Too many parts on Tinybird?

You still own table design: partition key, insert batching, materialized view memory. Tinybird owns the cluster, merge scheduling, and ingestion backpressure on the Events API and Kafka connector. A pathological schema will still hurt. It will not take down Keeper on a box you SSH into at 2 a.m.