ClickHouse hardware sizing starts with four workload inputs, not a server model
A team sizing a self-managed ClickHouse cluster needs CPU, memory, disk and replica counts that match its own workload, and those numbers come from measured inputs rather than from a server model chosen from a catalog. The four inputs that drive the calculation are concurrency (how many queries run at once and how heavy they are), ingest throughput (rows or bytes per second arriving and how often they arrive in batches), data volume (the compressed size of data after ordering and compression), and retention (how long each dataset must stay queryable). Until a team has numbers for all four, any hardware recommendation is a guess. This page explains how those inputs map to CPU, memory, disk and replicas, what the vendor publishes as starting ratios, and where the team must test before buying hardware.
This page covers the sizing method and the decisions behind it, from workload measurement through node profiles, disk layout, replica counts and Keeper placement, and it finishes with a validation step. It is written for platform, infrastructure and data leads who are deciding whether their own team will size, buy and run the cluster or whether a partner will do part of that work. ClickHouse server is open source under the Apache License 2.0 (Apache-2.0), so the software carries no license fee, and the hardware, its capacity planning and its ongoing operation are the team's responsibility. ClickHouse Inc. sells a managed service, ClickHouse Cloud, but this page assumes the cluster runs in infrastructure you control.
Before reading the sizing sections, confirm which ClickHouse release line you will run, because the supported versions and upgrade cadence affect how long a cluster sits on one set of hardware. The ClickHouse production FAQ recommends stable releases for most production use and a pre-production environment with representative data and queries. Build that test environment early, since a sizing estimate that has never been run against your own queries and data is only a starting point. Ask your vendor or partner to state, in writing, which measurements they will use to validate their estimate before a purchase order is raised.
Which four inputs drive CPU, memory, disk and replica counts
Every server count, memory figure and disk estimate for a self-managed ClickHouse cluster traces back to four inputs: how many queries run at once, how fast data arrives, how much data you keep, and how much availability you need. Measure each one in your own systems before you compare hardware options or ask a partner for a quote.
Query concurrency and weight
Count how many queries run at the same time at peak, and how heavy each one is. Pull this from your current query logs, dashboard refresh schedules and API call rates, grouped by the hour of the day that matters most. A few dashboards that scan years of data cost far more than many small point lookups, so record scanned rows and bytes per query, not only query counts. Confirm which users and services will share the cluster, because shared clusters need headroom for their combined peaks.
Ingest throughput and batching
Measure rows and bytes per second at peak, and the size of each insert batch as sent by producers. ClickHouse handles large, infrequent batches far more efficiently than many single-row inserts, so the batch size your pipeline produces matters as much as the total volume. Check whether ingest is steady or arrives in bursts, such as a nightly export or a traffic spike, because bursts set the capacity you must reserve. Ask the team that owns each producer for its actual numbers rather than design targets.
Data volume and retention
Work out raw size per day from your source logs or event exports, then apply the compression you measure on a sample loaded into a test table, since compression depends heavily on the data's shape. Multiply by the retention period you need for operations, audit and legal holds, and note which tables need different retention. Disk, backup storage and the time to restore all grow with this figure, so it sets more than storage cost alone.
Replication and availability needs
Decide how many copies of each dataset must survive a node or site failure, and how long the business can run on fewer replicas. Replication keeps data available when a server fails, but it multiplies disk use and adds write work on every copy. ClickHouse Keeper also needs its own nodes, and the replication guide recommends at least three on dedicated hosts in production. Document the recovery target you agreed with the business before deciding whether a second site is required.
Restore and backup headroom
Estimate how much space backups and restore tests need, and how long a restore takes on the hardware you will actually have during an incident. A backup that was never restored may not work when you need it, so plan regular restore tests on a spare cluster, and count that capacity in the sizing. Ask your team how long it can tolerate the data being unavailable, then compare that with the restore time you measured.
How the production guidance shapes the starting point
The ClickHouse production FAQ recommends stable releases for most production use and a pre-production environment loaded with representative data and representative queries. Treat that second point as the first sizing step. Any memory, disk or CPU figure you derive from ratios is a hypothesis until you have measured it against your own event volumes, query shapes and merge behavior on a cluster that resembles production. Plan the pre-production run before you order hardware, and include peak ingestion and your heaviest dashboards or scheduled queries in it, since those set the concurrency ceiling.
The release lines differ in how long you can stay on them. 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 a year after release. The security policy lists which versions currently receive security updates, and everything outside that list is unsupported. Check the ClickHouse GitHub releases page and the security policy on the day you size, because the version line you pick determines how long a given hardware plan stays supportable before an upgrade is required.
Version choice belongs inside the sizing decision, not after it. Memory use for merges, joins and aggregations, and disk layout for parts, can shift between releases, so a plan validated on one version is only partly validated on another. Record the exact version used in your pre-production test, and confirm with the changelog whether the target release changes behavior you rely on. Ask your deployment partner or internal team to repeat the measurement on the version you intend to run in production, and to reserve headroom for the upgrade you will need within the support window.
Sizing levers and when each one fits
This table compares the main levers for sizing a self-managed ClickHouse cluster, what each one changes, when it fits and what to confirm before committing. Read each row against your own concurrency, ingest rate and retention, since the right lever usually depends on whether the bottleneck is reads, writes, storage or availability.
| Lever | What it changes | When it fits | What to confirm |
|---|---|---|---|
| Replicas per shard | Adds read capacity and copies of each shard's data for failover | Query concurrency is high or a replica must survive a node loss | Replica count against query load and Keeper quorum, tested on your own query mix |
| Shards | Adds data volume and parallel write capacity across nodes | Ingest rate or total data outgrows what one node holds or writes | Shard key and how Distributed tables route inserts and queries |
| Larger nodes versus more nodes | Raises CPU, memory and disk per node or spreads the same load across more hosts | Few large nodes suit heavy merges and big queries; more nodes suit failure isolation | Merge and query memory peaks on your data, plus how many hosts your team can patch |
| Local NVMe or SSD versus HDD for hot data | Sets read and merge latency for recent data | Hot data is queried often and needs low latency | Sustained IOPS and write endurance under your ingest pattern, not just peak specs |
| Object storage tiers for older data | Moves rarely read data off local disks at lower cost per terabyte | Retention is long and older data is queried infrequently | Query latency on cold data and whether your ClickHouse version supports the disk type you plan to use |
| Dedicated Keeper hosts | Isolates coordination from query and merge load | Production clusters, where the replication guide recommends at least three Keeper nodes on dedicated hosts | Roughly 4 GB RAM per Keeper node, plus host placement that keeps a quorum through a single failure |
| Co-located Keeper | Saves hosts but shares CPU, memory and disk with ClickHouse | Non-production or small test environments only | Whether Keeper latency stays stable during heavy merges and backups |
| Stable release line | Gives monthly releases with the three latest stable versions receiving fixes | Teams that can upgrade often and test each release in a pre-production environment | Current supported versions in the security policy and the changelog for breaking changes |
| LTS release line | Gives releases twice a year, each supported for about a year | Teams that prefer fewer, longer-lived upgrades and a slower change cadence | Support end dates for your chosen line and whether needed features are in it |
Sizing paths for ingest-heavy, query-heavy and mixed workloads
Event, log and telemetry streams are dominated by write volume: how many rows arrive per second, how large each batch is, and how much background merge work those parts create. For this path, the sustained insert rate, the number of parts the server must merge, and the disk write throughput weigh most, while query concurrency is usually a secondary input. Memory and CPU are consumed mostly by inserts and merges, so the question is whether the cluster keeps up with arrival rate without the part count growing.
- Measure the arrival profile first: capture peak and average rows and bytes per second per table, plus the batch sizes your producers send. Small, frequent inserts multiply parts and merge work.
- Watch the part count: confirm that the number of active parts per partition stays bounded under sustained load, since a growing count signals that merges cannot keep up.
- Weigh disk throughput over capacity: merges rewrite data, so sustained write and read bandwidth on the data disks can bind before storage fills. Review the disk and filesystem guidance before choosing layouts.
- Check batching and buffering options: the levers around insert batching, async inserts and the ordering key shape merge cost more than adding query threads.
- Test on pre-production: replay a representative peak window at full rate, with merges running, and measure lag, part counts and replica delay. Confirm the replica catches up after a simulated restart.
Before accepting any hardware plan, check that the pre-production replay used real batch sizes and real peak timing, not a flat synthetic rate.
Dashboards and ad hoc analysis are dominated by read concurrency and per-query cost: how many users or services query at once, how many rows each query scans, and how long they are willing to wait. For this path, the number of concurrent queries, the data scanned per query, and the memory each query may use weigh most. Insert volume usually matters less, but it still affects query speed if it creates many small parts, so it must be measured too.
- Profile the query workload first: collect the query log for representative days, grouped by normalized query text, user and time of day. A few repeated dashboard queries often drive most of the load.
- Size against peak concurrency: determine the highest number of simultaneous queries and the memory and CPU each one uses at its peak, not the average.
- Review the ordering key and skip indexes: the schema determines how much data each query reads, and this usually changes the hardware need more than adding cores does. See the performance tuning topic for the options.
- Set resource limits deliberately: query memory limits, thread limits and quotas protect the cluster from a single heavy user. Decide these limits before testing, so results reflect the intended policy.
- Test with real concurrency on pre-production: replay the captured query mix at peak concurrency against representative data volume, and measure tail latency, not only the median. Repeat the test after a replica is taken out of service.
Confirm that the test data volume matches production, because cache behavior and scan cost change significantly when the data no longer fits in memory.
Most real deployments combine continuous ingestion with interactive queries, and a retention policy deletes or moves old data on a schedule. The sizing problem here is contention: inserts, merges, TTL work and queries compete for the same CPU, memory and disk bandwidth. The inputs that weigh most are the peak combined load, the retention window that sets total stored volume, and the replica count needed for availability, which together determine whether the same hardware serves both paths without one degrading the other.
- Model the overlap, not the averages: identify the hours when heavy ingestion coincides with heavy dashboard use, and size for that window. Batch reporting jobs that run at the same time as merges are a common source of contention.
- Size storage from retention: multiply the daily ingest volume by the retention period and the replication factor, then add headroom for merges and temporary space. Confirm the compression ratio on your own data rather than assuming one.
- Separate background work from queries: TTL deletions, merges and backups compete with user queries, so review the resource controls and schedule heavy maintenance off-peak.
- Plan replicas for availability: the replica count and Keeper layout determine how much load a single failure can shift onto remaining nodes. Size each node to handle the load of a failed peer during the peak window.
- Test the combined scenario: run ingestion, the captured query mix and a TTL or backup job together on pre-production, then measure query latency and insert lag. Repeat with one node down to confirm recovery behavior.
If the combined test fails only during the overlap window, adjust the schedule or resource limits before buying more hardware.
How to build a sizing estimate and validate it before purchase
This sequence turns assumptions about ingest, queries and retention into a tested node count and size, so the purchase rests on measured behavior rather than vendor ratios alone.
Collect current and projected workload data
Your data platform team gathers ingest rates in rows and bytes per second, the peak and average query concurrency, the query mix (dashboards, ad hoc analysis, exports), and the growth forecast for the next planning horizon. Where ClickHouse already runs, pull these figures from system tables and query logs. Where it does not, record the source systems, event volumes and the business users who will query the data. The step is done when every figure has a named owner and a source, and the team can explain which numbers are measured and which are forecasts.
Define retention and replica policy
Decide how long each table keeps raw data, which rollups or aggregates survive longer, and how many replicas each shard needs for availability. Record the recovery expectations that drive the replica count, including how many node losses the cluster must absorb without losing query service. Confirm with your compliance and risk owners whether retention is set by regulation or internal policy. The output is a written retention table per dataset and a replica decision, which together fix the disk multiplier that the sizing model must cover.
Build a pre-production cluster with representative data
Stand up a non-production cluster on the same server class you are considering, using the same ClickHouse release line you plan to run in production. Load a representative slice of real data, ideally covering the full table structure, compression profile and partition layout, and run the actual dashboards and queries your users depend on. The vendor's production guidance recommends a pre-production environment with representative data and queries, and reading the changelog for the chosen release before upgrading. The check is that data loaded into the test cluster matches the production schema and that query results agree with the source systems.
Run a load test at peak concurrency
Replay the peak ingest rate and the peak query concurrency from step one against the pre-production cluster, running inserts and reads at the same time, since that combination is what usually exposes contention. Use a load generator your team controls, and keep the query mix close to the recorded production pattern. Capture p95 and p99 query latency per dashboard or API endpoint, along with insert throughput. The check is whether latency stays within the target your business owners agreed to and whether inserts keep pace without errors.
Measure CPU, memory, disk growth and merge backlog
During the load test, record CPU use per node, memory peaks including caches and query memory, disk consumption, and the number of parts and background merges over time. Project disk growth by multiplying the observed daily stored volume by the retention window, then add headroom for merges, replication and the backups you plan to keep locally. The check is that merge backlog stays bounded, meaning the count of parts settles rather than climbing through the test, and that projected disk use fits within the planned capacity with room to spare. Confirm the backup target also has capacity for the chosen backup schedule.
Adjust node size or count and rerun
If the load test misses latency, shows unbounded merges or projects disk use beyond capacity, change either the node size (CPU, memory or disk) or the node count, then repeat the load test on the adjusted configuration. Keep a record of each run so the team can show which change fixed which constraint. Include a restore test in this loop: restore a backup of the test data onto a spare cluster and confirm the restored row counts and key queries match. The vendor's backup documentation warns that a backup never test-restored will probably not restore properly when needed. The loop ends when every target is met on a configuration with explicit headroom.
Document the sizing decision and its assumptions
Write a sizing record that states the workload inputs, retention and replica policy, the tested configuration, the measured results from each run, and the assumptions that would invalidate it, such as a new source system or a higher query concurrency. Include the restore test result and the upgrade assumption for the chosen release line. Ask the vendor or a quote provider to map the tested configuration to their own line items so the purchase references the validated design. The record is complete when a second engineer can rebuild the cluster from it and reach the same measured results.
Limits to confirm in your environment before you buy hardware
Hardware sizing rests on assumptions that change with the software release, the operating system, the storage layer and the platform underneath the servers. Each card below names one assumption, who can confirm it, and what to ask for before a purchase order is raised.
Sizing guidance for your version
Sizing ratios and memory behavior can shift between ClickHouse releases, so a ratio taken from an older guide may not hold for the line you deploy. Ask the vendor which guidance applies to the stable or LTS line you plan to run, and confirm that line is still in its supported window. Check the security policy and release notes for the version you are targeting before you commit to a server profile. Record the answer in the sizing worksheet so the purchase reflects a specific release.
Linux and storage stack behavior
CPU governor, memory overcommit, transparent huge pages and the disk layout all change how a given server performs under the same load. Those settings are covered in the operating system tuning and disk and filesystem topics, so do not size from raw hardware specifications alone. Ask your infrastructure owner which kernel, filesystem and RAID layout the fleet standard uses, then test a representative node with that stack before scaling the purchase.
Data volume growth beyond projections
Retention and ingestion projections often miss new log sources, verbose debug fields and a growing number of tenants. Ask the data owners for the expected ingest rate in a peak hour, not only the daily average, and ask which sources are planned in the next year. Compare the projection with actual volume from a pilot run. Treat the gap as a sizing input for disk and replica count, not as a footnote.
CPU and memory allocation by the platform
A hypervisor or Kubernetes node pool may overcommit CPU, reserve memory for system daemons, or cap a pod below the host size. Each of these changes the effective capacity that ClickHouse sees. Ask the platform team how vCPUs map to physical cores, what memory limits apply to the ClickHouse pods or virtual machines, and whether CPU passthrough is enabled. Confirm these answers with a measured run on the target platform.
Network bandwidth between replicas and Keeper
Replicated tables move parts between replicas, and Keeper nodes handle coordination traffic that must stay responsive during merges and recovery. A replica that resyncs after a failure can saturate a link that looked sufficient during normal operation. Ask the network team for the bandwidth and latency between each replica pair and to each Keeper node, and whether those paths cross shared uplinks. Check Keeper placement against the replication guide before fixing the node count.
Capacity you cannot skip: backups, restore tests and replica recovery
A sizing estimate that covers only normal query and ingest load will be short for the events that matter most. Add headroom for three things before you fix the disk and node counts: the space and I/O for backups, the time and capacity needed to run restore tests, and the spare resources a replica consumes while it catches up after a failure. ClickHouse BACKUP and RESTORE can write full and incremental backups of tables, partitions or databases to local disk, S3-compatible storage or Azure Blob Storage. Confirm which destination your organization will use and whether its throughput and retention fit the backup window you set. Ask the vendor or your storage team for the measured write rate of that target, since the documentation does not give a number you can plan with.
Replication is not a backup. The replication guide describes ReplicatedMergeTree tables coordinated by ClickHouse Keeper, and a healthy replica will faithfully copy a bad DELETE, a dropped partition or corrupted data to every other replica. The backup documentation says so directly, and it also warns that a backup never test-restored will probably not restore properly when needed. Plan a recurring restore test on a spare cluster sized to hold a restored copy of the data you intend to recover. Budget the nodes, disks and network for that cluster as an ongoing cost, not a one-time project, and record how long a restore took so the recovery time you promise is based on evidence.
When a replica fails and returns, it automatically syncs missing data from a healthy replica without manual intervention. That convenience has a cost: the healthy replicas must read and send parts while still serving queries and ingest. Size the surviving replicas so one can fail and the rest still carry peak load plus the fetch traffic. Check Keeper capacity as well, because the replication guide recommends at least three Keeper nodes on dedicated hosts in production. Run a rehearsal in which you stop one replica under representative load and measure catch-up time, network use and query latency. The results will show whether your replica count is enough or whether you need more headroom in CPU, memory and disk.
What buyers ask about ClickHouse hardware sizing and outside help
What drives the cost of ClickHouse hardware sizing work?
The cost follows the written scope: how many workloads are in view, how much workload data exists to measure, whether a pre-production environment with representative data is available, and how much load testing the sizing must be checked against. Fixed-scope work is agreed in writing before it starts, so the quote lists the deliverables, such as a sizing model, a recommended topology and a test plan. Ask the provider to itemize measurement, environment setup, load testing and the written report, so you can see which parts your own team could take on. DeployOpen does not publish a price list, and a quote follows from that scope.
Can our own team size a self-managed ClickHouse cluster without a partner?
Yes, a capable team can size a cluster on its own if it has two things: workload data and a test environment. Workload data means query logs, ingestion rates, peak concurrency, data volume and the retention policy the business requires. A test environment means a non-production cluster loaded with representative data and queries, so sizing assumptions can be checked before purchase. Without those inputs, the estimate rests on guesses. A partner is most useful when measurement, load testing or the review of the result needs experience your team does not have yet.
How long does ClickHouse sizing take, and what sets the duration?
The duration depends on scope, on how quickly usable workload data becomes available, and on the number of test cycles needed to confirm the sizing. A single workload with clean logs and an existing test environment moves faster than several workloads that need new instrumentation. Timelines should be stated in the written scope and tied to the client's dependencies, such as access to query logs and to the infrastructure owners who approve hardware. Ask for the planned test cycles and the conditions that would extend them, rather than a single headline number.
What does the client need to provide for the sizing work?
Plan for four inputs. First, workload logs covering query patterns, ingestion throughput and peak concurrency over a representative period. Second, a written retention policy that states how long each dataset must stay online and what must be archived. Third, access to a pre-production or test environment with enough capacity to run realistic load. Fourth, named infrastructure owners who can confirm server, storage, network and cloud constraints and approve the chosen configuration. Missing any of these usually extends the work, so confirm availability before the scope is signed.
What recurs after a ClickHouse cluster goes live?
Sizing is not a one-time event. Ongoing work includes monitoring resource use, such as CPU, memory, disk and merge activity, and resizing as data volume and query load grow. It also includes upgrades. Stable releases ship roughly monthly, and the vendor's production guidance recommends a pre-production check of each upgrade, while LTS releases ship twice a year and are supported for a year. Keeping to a chosen upgrade path, and re-running load tests before hardware changes, keeps the sizing accurate. Budget for these activities as recurring operations, whether your team or a retainer carries them.
Does DeployOpen provide cost figures for ClickHouse sizing?
DeployOpen does not publish a price list for ClickHouse sizing, so there is no standard figure to quote. A price follows from a written scope that names the workloads, the workload data available, the test environment, the load testing required and the deliverables. Ask for a quote that separates one-time sizing work from any recurring support or upgrade retainer, and ask what assumptions the quote depends on. If a scope changes after signing, the change should be agreed in writing before the work continues.
Is ClickHouse itself licensed in a way that affects hardware planning?
The ClickHouse server is open source under the Apache License 2.0, so the software itself carries no per-core or per-node license fee for self-managed use. Hardware planning still has real costs, including servers, storage, network, Keeper nodes and the staff who run them. ClickHouse Inc. sells ClickHouse Cloud as a managed service, which is a different cost model. Confirm the license terms of any add-on tools or connectors your architecture includes, since they are separate from the server.
How DeployOpen scopes, delivers and supports ClickHouse sizing
DeployOpen approaches ClickHouse hardware sizing as a written, fixed-scope piece of work that starts from your concurrency, ingest rate, data volume and retention targets. We plan, build and test the sizing in infrastructure you control, then document the result so your team can keep it current.
How we scope
- Written scope lists the workloads, query patterns, ingest rates and retention periods the sizing must cover.
- We confirm which environments exist, such as pre-production with representative data, and what hardware or cloud accounts you control.
- Deliverables, exclusions and acceptance criteria are agreed in writing before any sizing work starts.
How we build
- We build a sizing model for CPU, memory, disk and replica counts, then test it against representative queries and load.
- Keeper node placement, shard and replica layout, and storage headroom are checked against your failure and growth assumptions.
- We validate the sizing on a pre-production cluster before any production hardware order or configuration is finalized.
How we hand over
- You receive the sizing worksheet, assumptions, test results and the configuration files used for the recommended layout.
- Documentation explains which inputs drive each figure, so your team can rerun the model when volumes or query mix change.
- We walk your engineers through the results and the points to recheck before each ClickHouse upgrade or major data growth.
How we support
- Ongoing support, periodic resizing reviews and continuous testing are available as a retainer, scoped separately in writing.
- Support can cover re-running the model after release changes, reviewing new hardware options and updating disk and replica plans.
- Confirm with DeployOpen during scoping which support hours, response paths and review cadence the retainer includes.
