What this service covers and when teams need it
The ClickHouse server is licensed under the Apache License 2.0, so running it yourself carries no license fee for the software. The cost of ownership sits elsewhere: compute, storage and object storage tiers, ClickHouse Keeper nodes, the people who operate the cluster, and any support agreement you buy. ClickHouse Inc. separately sells ClickHouse Cloud as a managed service, so the comparison your steering committee asks for is really between your own infrastructure costs and staff effort on one side and a managed subscription on the other.
Teams usually start this work for one of four reasons: a steering committee asks for a multi-year comparison before committing budget, a cloud contract renewal forces a decision, a move from a commercial warehouse or log platform is already planned, or data residency rules require self-hosting. Each trigger changes which cost lines matter most. A renewal date sets the time horizon, while residency requirements can rule out a managed option before pricing is even discussed.
For a simple, single-environment comparison, most teams can build the model in-house using their own cloud price sheets and a realistic staffing estimate. Bring in a partner when the comparison touches compliance evidence, several environments such as development, pre-production and production, or a need for a fixed-scope quote covering operations. Ask any partner to show the written scope behind each cost line, including Keeper hosts, backup storage, upgrade effort and who carries the on-call duty.
What the cost model includes
Every cost of ownership engagement starts from the same inputs and ends with the same deliverables: a model with stated assumptions, a sensitivity view, a written summary for decision makers and a recommended operating model. The comparison against ClickHouse Cloud and up to two other managed options you name runs on those same inputs.
Workload inventory
The model starts with a workload inventory: sustained ingest rate, peak ingest windows, retention period per table, and the query patterns that drive load, such as time-range scans, joins and dashboard refresh frequency. Ask for each figure to be tied to a named source system, because every later line item depends on these inputs.
Compute, memory and disk sizing
Sizing converts the inventory into node counts for CPU, memory and local disk per shard and replica. Memory demand follows concurrent queries and joins, while disk follows compressed volume after the sort key and codecs are chosen. Confirm how the compression assumptions were measured, since an untested ratio can move the total more than any unit price.
Storage tiers and object storage
The model separates hot data on local disks from older data that may move to object storage, if your chosen storage configuration supports that tier for the tables in scope. Price each tier separately, including request and data transfer charges, and confirm with your team how queries against cold data perform before assuming that keeping it there is inexpensive.
Keeper node model
ClickHouse Keeper coordinates ReplicatedMergeTree replication. The replication guide recommends at least three Keeper nodes on dedicated hosts in production, with about 4 GB of RAM each. Include those hosts, their patching and their monitoring in the cost, because they are separate machines that consume operator time like any other production node.
Backup and restore storage
Backup storage depends on retention, the full and incremental backup schedule, and the target: local disk, S3-compatible storage or Azure Blob Storage. Replication does not protect against human error or corruption, so the model also needs spare cluster time for the regular restore tests that the backup documentation recommends.
Staffing and support assumptions
Staffing is often the least visible cost. State the hours for upgrades, on-call, capacity reviews and access administration, and name who owns each task. Record the release line you assume for upgrades and whether a support agreement is part of the operating model, since both change the effort your team carries each year.
What drives the cost and how to keep it down
This table lists the main drivers of self-hosted ClickHouse cost and effort, why each one moves the bill or workload, and one practical way to reduce it.
| Driver | Why it moves the cost | How to keep it down |
|---|---|---|
| Data volume and retention period | Stored volume multiplies through replicas and backups, so every extra month of retention adds recurring disk cost. | Set retention per table with TTL rules, and move older partitions to cheaper storage tiers where your hardware allows. |
| Ingest rate and burstiness | Sizing follows the busiest hour, since peak inserts drive merge CPU and disk I/O. | Batch inserts into fewer, larger writes and buffer bursts in your ingestion pipeline before they reach the cluster. |
| Query concurrency, latency targets and teams sharing the cluster | More simultaneous users and tighter latency targets need more CPU, memory and sometimes additional replicas for read load. | Set query quotas and settings profiles per team, and agree latency targets for each dashboard class in writing. |
| Replica and shard count | Each replica stores a full copy of its shard, so replicas multiply disk and compute. Shards add capacity but more nodes to run. | Start with the fewest shards that meet measured load, and add replicas only for availability or read capacity you can name. |
| Environments (production, pre-production, restore test) | Each environment is a second or third cluster to run, patch and monitor. Pre-production needs representative data, which adds storage. | Size pre-production smaller but keep representative schema and query patterns, and reuse the restore-test cluster for upgrade trials. |
| Keeper node placement | Production replication needs at least three Keeper nodes on dedicated hosts, each with about 4 GB of RAM per the ClickHouse replication guide. | Run Keeper on small dedicated VMs in separate failure domains, and avoid co-locating them with heavy merge workloads. |
| Backup frequency and retention | Backup storage grows with each retained full and incremental set, and restore tests consume spare capacity. Replication does not replace backups. | Use incremental backups between scheduled fulls, set retention by recovery need, and test restores on a spare cluster on a schedule. |
| Compliance requirements such as data residency or audit logging | Residency rules can force a second region or site, and audit logging adds query log storage and review effort. | Confirm the residency and audit requirements with your assessor early, then set log retention to the minimum the evidence requires. |
| Upgrade cadence (monthly stable or twice-yearly LTS) | Monthly stable releases mean more upgrades per year. LTS releases mean fewer, but each upgrade carries more change. | Choose the cadence your pre-production testing can absorb, and confirm each version is on the security policy's supported list. |
How the cost model is built
The sequence turns scattered workload and spend data into a multi-year comparison of self-hosted and managed ClickHouse that finance and platform owners can challenge and decide on.
Collect workload and current spend data
We inventory the workloads that will run on ClickHouse, including data sources, daily ingest volumes, retention requirements, query patterns and concurrency, and collect current spend on compute, storage, object storage, licenses and support. The output is a workload register and a spend baseline that the client's platform and finance owners have reviewed for accuracy.
Capture assumptions with finance and platform owners
We meet the client's finance and platform owners to agree on the assumptions the model depends on, such as hardware or cloud pricing, staffing for operations, discount terms, growth rates, the planning horizon and the cost of downtime. Each assumption is recorded with an owner and a source, and the output is a signed-off assumptions sheet that the model is built from.
Build the self-hosted and managed options model
We build the multi-year model for self-hosted ClickHouse and for each managed option the client wants to compare, including ClickHouse Cloud. Compute, storage tiers, object storage, Keeper nodes, backup storage, people, support and upgrade effort are modeled separately, with one-time and recurring costs kept apart. The output is a working model with every line traced to an assumption.
Validate the model against a pre-production sizing test
Where the client agrees, we run representative data and queries on a pre-production cluster and on the managed option under evaluation, then compare measured resource use with the model's sizing. Results that differ from the model are explained and the assumptions are adjusted. The output is a validated model or a list of open variances with their effect on cost.
Review the model with decision makers
We walk the decision makers through the model, the sensitivity of the result to each key assumption, the risks that are not priced, and the options considered and rejected. The review closes when the client records which option it chooses, which assumptions need monitoring and who owns the model going forward.
Recurring costs after go-live
Each recurring cost line for a self-hosted ClickHouse cluster, showing whether it is one-time or recurring, who pays, and which lines a managed service such as ClickHouse Cloud may absorb.
| Cost line | One-time or recurring | Who pays | Managed service absorbs |
|---|---|---|---|
| Compute for ClickHouse servers | Recurring | Your cloud account or data center budget | Often, depending on the offer. Confirm instance sizing and what the provider bills. |
| Memory and local disk | Recurring, with one-time sizing work | Your infrastructure budget, scaled by data volume and query concurrency | Often, depending on the offer. Confirm storage limits and tier pricing in writing. |
| Object storage tiers | Recurring, growing with retention | Your cloud account or storage team | Partly. Ask which storage tiers and retention policies the provider includes. |
| Keeper hosts (three or more, dedicated) | Recurring | Your infrastructure budget. The replication guide recommends about 4 GB of RAM per node. | Usually not applicable to the managed service. Confirm how coordination is handled. |
| Backup storage on local disk, S3-compatible or Azure Blob Storage | Recurring, growing with backup retention | Your cloud account or storage team | Confirm whether backups, retention and restore tests are included in the managed plan. |
| Network egress between sites | Recurring, driven by replication and backup traffic | Your network or cloud provider, billed by volume | Depends on the deployment. Ask where data flows and who pays for cross-site transfer. |
| Monitoring | Recurring, from tooling and staff time | Your observability tooling and platform team | Partly. Ask which metrics, alerts and log access the managed service exposes to you. |
| Staff time for upgrades and restore tests | Recurring, tied to the release cadence | Your platform or database team, or a partner under a retainer | Partly. Upgrades and patching may be included. Restore tests on your own data usually remain your duty. |
| Vendor or partner support | Recurring, when you buy a support agreement | Your organization, under a support contract with a vendor or partner | Included in some managed offers. Confirm response times and what the agreement covers. |
How the cost picture changes by starting point
Teams leaving a commercial cloud warehouse usually carry a one-time migration cost, and the lines that shift most are those that run in parallel while old and new systems both serve queries.
- Dual running: the warehouse and ClickHouse both run until reports, dashboards and downstream jobs are verified, so both bills overlap for that period.
- Query rewrites: dialect differences and table redesign are labor costs, paid to your team or to a partner.
- Data export: moving historical data out of the warehouse may carry transfer charges, which you should confirm with your provider.
- Keeper hosts: if you replicate for availability, Keeper on dedicated hosts becomes a recurring line that the warehouse bill previously covered.
- Object storage: existing buckets may hold backups and cold data, which can change the new storage line depending on volume and tiering.
Teams moving from a log platform or Elasticsearch often see the largest changes in ingestion and retention, because both depend on how events are shaped before they are stored.
- Parallel ingestion: events may need to flow to both systems during validation, which doubles pipeline load for that period.
- Index-to-table design: mapping indices, fields and retention rules to ClickHouse tables is design and build effort that recurs whenever new log sources are added.
- Backfill: reloading historical data costs compute and time, and the amount depends on how much history you keep.
- Licensing: the existing platform's license or subscription may run until dashboards and alerts have been moved, so confirm the end date with its vendor.
- Dashboard rework: visualization tools such as Grafana may be retained, but queries behind each panel still need rewriting and testing.
A fresh build has no migration or dual-running line, so the cost picture centers on design, sizing and operating the platform from the start.
- Sizing and testing: a pre-production environment with representative data and queries is recommended for production use, and building it is a one-time cost.
- Collection pipeline: instrumentation and collector configuration, for example with OpenTelemetry, is effort that recurs as services change.
- Keeper hosts: if tables are replicated, the replication guide recommends at least three Keeper nodes on dedicated hosts in production, each with about 4 GB of RAM, so ask for these hosts to be priced separately.
- Backup and restore tests: backup targets and regular restore tests on a spare cluster are recurring costs that a fresh build must include from day one.
- Staffing: the skills needed to tune sort keys, watch merges and manage upgrades are the main ongoing people cost.
In regulated or air-gapped environments, most cost lines sit inside your own infrastructure, so hardware, staffing and evidence work carry more weight than vendor fees.
- Infrastructure: compute, storage and dedicated Keeper hosts are purchased or reserved in your data center or accounts, and capacity planning must cover restore test clusters too.
- Offline updates: air-gapped networks need a process to bring approved packages in, test them and deploy them, which is recurring staff time.
- Supported versions: the security policy lists supported versions, and staying on one requires scheduled upgrades that your team or a partner must fund.
- Access and audit evidence: access control, authentication and log retention settings must be documented for assessors. DeployOpen prepares this evidence, but independent auditors issue any assessment result.
- Backup location: backups to on-site object storage or local disk avoid external dependencies, but need their own capacity and protection.
Organizations that already run Kubernetes may reuse nodes and storage classes, but the replication guide's advice on dedicated Keeper hosts limits how much spare capacity can absorb.
- Spare nodes: unused worker capacity may cover ClickHouse pods for a single-site deployment, which can reduce new hardware purchases.
- Keeper placement: production Keeper nodes are recommended on dedicated hosts, so shared spare capacity may not cover them and that line should be confirmed early.
- Storage performance: persistent volumes shared with other workloads may not meet the disk throughput needed for merges and queries, so confirm storage class performance before counting it as free.
- Operator maintenance: running the ClickHouse operator and cluster upgrades alongside the shared platform adds recurring coordination work.
- Object storage reuse: existing S3-compatible storage may hold backups, which changes the backup line, but restore tests still need capacity.
What usually goes wrong in cost estimates
Most ClickHouse estimates miss the same few items. Each card names one gap and gives the step that prevents it.
Keeper and backup storage omitted
ReplicatedMergeTree tables depend on ClickHouse Keeper, and the replication guide recommends at least three Keeper nodes on dedicated hosts in production, with about 4 GB of RAM each. Backups to S3-compatible or Azure Blob storage are a separate line item that grows with retention. Prevention: list Keeper hosts and backup capacity as named items in the estimate before the compute budget is final.
Single-node layout assumed as production
The default single-node setup suits evaluation, but production replication and sharding multiply hosts, disks and network traffic. Each replica and shard needs its own compute and storage, and Keeper runs beside them. Prevention: model the target shard and replica topology in the estimate so it matches the layout you will actually run.
Restore tests left out of the budget
The backup documentation warns that a backup never test-restored will probably not restore properly when needed, and it recommends regular restore tests on spare clusters. A spare cluster costs compute and storage, and someone must run and record each test. Prevention: budget a recurring spare cluster and restore test schedule as its own line item.
Replication treated as backup
A recovered replica syncs missing data from a healthy one automatically, so a bad DROP, a faulty DELETE or a corrupted write can spread to every copy. The backup documentation notes that replication alone does not protect against human error or corruption. Prevention: fund backups with their own retention period and confirm who can restore a table to a point in time.
Upgrade effort and cadence underestimated
Stable releases ship roughly monthly, LTS releases twice a year, and the security policy lists only versions 26.9, 26.8, 26.7 and 26.3 as supported. Each upgrade needs changelog review, a run on pre-production data and queries, and a rollout window. Prevention: budget staff hours per upgrade cycle and a pre-production environment before committing to a cadence.
Managed list prices compared with unlabeled self-hosting
Comparing ClickHouse Cloud list prices with self-hosted hardware alone leaves out engineers, on-call time, Keeper and backup infrastructure, and support. Self-hosting costs recur each year through labor and infrastructure. Prevention: ask for a fully loaded comparison that includes staff time for upgrades and restore tests on both sides.
What the client needs to provide
The cost model is only as good as the inputs behind it, so the first task is to collect them before any comparison is made. Start with current spend and invoices for the incumbent platform or cloud service, broken out by compute, storage, data transfer and licensing. Where invoices are unavailable, ask for the billing exports or the cost allocation reports that finance already uses. Finance should confirm that these figures are complete and cover the same period as the usage metrics.
Next, provide ingest and query metrics for at least the period you can export. Useful measures include rows or bytes ingested per day, peak ingest rate, query volume, the share of queries that scan recent data versus history, concurrency at peak, and how long queries are allowed to run. Also supply retention requirements by data class, such as raw events, aggregated tables and audit logs, with the legal or policy basis for each. Platform owners should sign off the metric definitions, and the data owner should sign off retention periods.
Document data residency and compliance constraints in writing. State which regions, data centers or air-gapped networks are permitted, whether object storage tiers may leave the country, and which controls apply to backups and replicas. Name the finance owner who will approve the total cost of ownership, the platform owner who will run the system, and the security owner who will accept residency and control assumptions. Confirm which managed options are in scope for comparison, since a self-hosted estimate and a managed estimate differ in what they include.
Finally, share any pricing quotes already received from ClickHouse Cloud or other managed providers, along with their stated scope, term and exclusions. Each assumption in the model, including staffing hours, growth rate and discount levels, should carry a named owner who signs it off in writing. Re-validate these inputs before the decision, because a model built on unsigned assumptions will be challenged in the approval meeting.
Frequently asked questions
Does self-hosted ClickHouse have a license fee?
No. The ClickHouse server is open source under the Apache License 2.0 (Apache-2.0), so there is no license fee for running it yourself. Your costs are the infrastructure it runs on, the people who operate it, and any support agreement you choose. ClickHouse Inc. separately sells ClickHouse Cloud as a managed service, so the comparison is between that service fee and your own run costs. Ask the vendor which commercial support terms and features, if any, apply to your use.
What does ClickHouse Cloud run that self-hosting leaves to you?
In ClickHouse Cloud, ClickHouse Inc. operates the managed service, so the provider runs the clusters, hosting and much of the day-to-day service operation. When you self-host, your team or partner runs the hosts, Keeper nodes, upgrades, backups, monitoring and access control inside your own cloud accounts or data centers. Confirm with the vendor exactly which operations, data residency options and availability commitments its service includes, and compare those terms with the work you would carry yourself.
Can our own team build a ClickHouse cost model?
Yes, if your team can collect the inputs. The model needs compute for servers, storage tiers for hot and cold data, object storage for backups and retention, dedicated Keeper hosts, people time, and support. The replication guide recommends at least three Keeper nodes on dedicated hosts in production, each with about 4 GB of RAM. Use your own cloud or data center rates for hosts, and request managed service pricing in writing from the vendor so both options are costed on the same workload.
Which ClickHouse versions should we plan around for production?
Plan around the versions listed as supported in the ClickHouse security policy: 26.9, 26.8, 26.7 and 26.3. Stable releases ship roughly monthly, and the three latest stable releases receive diagnostics and bug fix backports. LTS releases ship twice a year and are supported for one year after release. The GitHub releases page currently lists v26.9.20.23-stable as the latest stable release and the LTS lines v26.8.29.10-lts and v26.3.53.4-lts. Read the changelog before each upgrade, because minor backward-incompatible changes can occur, and test in a pre-production environment with representative data.
How does Keeper change the number of hosts we pay for?
Keeper adds hosts beyond the ClickHouse data servers. Replicated tables depend on ClickHouse Keeper for coordination, and the replication guide recommends at least three Keeper nodes on dedicated hosts in production, each with about 4 GB of RAM. Those nodes are a recurring compute cost even when data volume is modest, and they should be counted in every cost model. Your replica count and availability target decide the data host total, so ask your partner or team to size Keeper alongside the cluster design.
How do we request a fixed-scope quote for ClickHouse?
Send a written description of the workload and the outcome you need, and ask for a quote based on that scope. Useful inputs include expected data volume, ingest rate, retention periods, query concurrency, backup and restore requirements, regions or data centers, identity needs and the skills your team already has. DeployOpen does not publish a price list. Most engagements are fixed-scope, so the scope, deliverables and timeline are agreed in writing before work starts, and the quote follows from that scope.
How DeployOpen approaches this work
DeployOpen models the multi-year cost of running Apache-2.0 ClickHouse in infrastructure you control, then compares it with managed options using your own workload assumptions. The work is planned in writing before any build begins.
How we scope
- The written scope lists which ClickHouse components, hosting environments and managed alternatives the cost model covers.
- We agree the workload inputs with you: data volume, retention periods, query patterns and expected growth over the modeled years.
- Cost lines are split into compute, storage tiers, Keeper nodes, people, support and backup storage, each with a stated owner and basis.
How we build
- We build a spreadsheet-based model with explicit assumptions, so your finance and platform teams can change inputs and rerun the comparison.
- Each assumption is tied to a source you can check, such as your cloud price sheets, hardware quotes or ClickHouse Cloud pricing pages.
- We test the model against a pre-production sizing exercise with representative data, so storage and compute estimates reflect real behavior.
How we hand over
- You receive the model, its assumptions register and a written summary of the self-hosted and managed options compared.
- The handover explains which costs are one-time, which recur each year and which change with release cadence or support choices.
- We document the upgrade and support cost lines so your team can update the model when pricing, versions or staffing change.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer if you want the model refreshed as the platform evolves.
- A retainer can cover periodic reviews of supported ClickHouse versions, licensing terms and cloud price changes that affect the comparison.
- Confirm with us in writing which refresh cycle, review scope and response expectations apply before the retainer starts.
