How to pick the right server for ClickHouse

Welcome to part 1 of our ClickHouse series, where we break down the most important principles for running ClickHouse on dedicated servers, both for new and existing setups.

First and foremost, ClickHouse is remarkably efficient with resources, and it’s full of ingenious optimizations. A lot of “performance problems” don’t require new hardware at all. They disappear once you review your data batching, schema design, and query patterns... but that's a topic for another day.

This part of the series focuses purely on hardware selection for your dedicated bare metal ClickHouse setup. Treat the recommendations below as a baseline to start from, not a substitute for workload testing. For more tailored guidance, feel free to reach out to our experienced sales team anytime.

Our background with ClickHouse

We’ve been using ClickHouse in production for over 5 years as a cornerstone of our data processing pipelines. It helped us scale from processing a few million rows per second to tens of millions without turning our infrastructure into a science experiment.

If you want a bit more background on ClickHouse itself, PostHog’s in-depth article covers it pretty well. For this article, we’re focusing on the part people actually came for: picking the right hardware for a dedicated bare-metal ClickHouse deployment.

So, where do we start?

1. Define your use case first

Before looking at server specs, clarify what you’re actually asking the system to do. Key questions to answer:

What are my concurrency and throughput requirements?

• Concurrency and throughput are two separate dimensions worth thinking about independently.
• QPS (Queries per second) reflects concurrency and is primarily addressed by adding more CPU cores.
• RPS (Rows per second), both read and written, puts more pressure on Disk IOPS and memory bandwidth.

What latency and workload type am I optimizing for?

Cloudflare’s blog post is a good real-world example of a ClickHouse workload.

• Customer-facing workloads demand fast disk I/O and more memory.
• High-concurrency analytics benefit from more CPU cores.
• Data warehousing with large ad-hoc queries benefits the most from memory-optimized hardware.
• Get clear on which one dominates your workload before speccing anything out.

How much data (compressed) will I store per replica, and for how long? 

• ClickHouse can achieve exceptional compression ratios by good schema design, using the right data types, and ordering similar values together. Compression ratios of over 170x are achievable, as the ClickHouse team demonstrated with NGINX logs in their blog post. 

What are my availability and redundancy requirements?

• Even when using RAID for underlying storage, we recommend having at least 2 replicas (3 for critical data) per shard. This will also allow you to have upgrades without downtime [Official guide - Self-managed upgrade].

Even though it’s rarely this straightforward in practice, these questions are a reliable starting point for hardware sizing. What about actual hardware principles to keep in mind?

2. Don’t spread yourself too thin

A common mistake when setting up ClickHouse clusters is sharding too early. Let’s clarify two distinct terms: 

1. Shards determine how your data is horizontally partitioned across nodes. Each shard holds a distinct subset of your data, and adding more shards increases your total storage and write throughput capacity. 
2. Replicas are copies of a shard. Their primary goal is to provide reliability in case of node failure. However, in the latest versions, they can also help distribute read load. Note that these are independent dimensions.

A good rule is to scale up first (bigger nodes; more RAM, faster disks, etc.), and scale out only when a single node can no longer hold the shard or meet throughput requirements. In most cases, this approach means better value for money and less operational complexity. The ClickHouse engine is built to fully utilize all the available resources on the machine; hence, fewer strong nodes usually beat many small ones.

With a large cluster of low-grade machines, it’s easy to end up with: 

• Slow query finalization on the initiating node.
• Memory pressure, which can lead to failed queries.

The main reason is that even though ClickHouse distributes queries across all shards and even multiple replicas, the partial results need to be joined on the node that received the original query.

As mentioned, we recommend starting with 1 shard with 2 replicas, or 3 if the data is really critical. Don’t introduce another shard until you can no longer get a more powerful machine.

One key thing to note is that using replication requires a separate coordination cluster using either ZooKeeper or Keeper. That topic is out of scope for this blog post, but keep in mind that while these instances are not computationally intensive, ClickHouse will fall into read-only mode without them.

3. Aim for a lot of CPU cores

More cores mean more power to process tasks in parallel. ClickHouse is designed to take full advantage of this, parallelizing query execution across all available cores, which the ClickHouse team demonstrated in their blog post. While it focuses on Intel Xeon processors, the same principles apply to AMD EPYC-based hardware. In our own testing on the EPYC 9754, ClickHouse can utilize all 128 cores under load.

Aiming for the highest core number rather than the highest CPU frequency also means disk accesses will benefit greatly under the concurrent load of multiple tables writing new data, merging existing ones, and executing user queries. CPU frequency has a less dramatic effect. It impacts the normal operating range of CPU usage and the latency of ad-hoc queries. Overall throughput in ClickHouse usually scales more with the number of CPU cores.

What about CPU utilization targets? The official ClickHouse documentation notes that there is no universal CPU utilization target, but recommends 10–20% for analytical and data warehousing workloads with ad-hoc queries. In our experience, many production workloads perform well at 30-40% sustained usage. Even 50–60% is perfectly fine for workloads that are less latency-sensitive or for which only moderate growth is anticipated. Just make sure you leave enough headroom for traffic spikes and background merge operations.

4. How much RAM is enough? 

ClickHouse benefits massively from RAM. Beyond the working memory it uses directly for query execution and background tasks, the rest isn’t wasted. It’s used as an OS page cache to keep hot data in memory and speed up subsequent queries.

The official documentation lists 32 GB of RAM as a sensible production minimum for a server, although ClickHouse can run on much less with additional tuning. (Yes, you can easily run ClickHouse on your laptop.) 

Based on our experience, here's a simple rule of thumb to get you started:

• 64 GB is our recommended starting point if you want a system that behaves like production. Any “extra” memory is rarely wasted. It’s effectively used for page cache and I/O buffers (metadata/block cache).
• 128 GB is recommended by the official documentation for moderate scale (more than 25 TB of data per server).
• 256–512 GB should be considered when:
  1) You expect to be processing gigabytes of data per query result.
  2) Your data source can sustain a high data rate (hundreds of thousands of rows per second), for example after a network partition. In this case, input batching, typically referred to as asynchronous inserts, can itself allocate several GB of memory.
  3) You run very complex queries that require a large amount of working memory.

Another important factor is the RAM-to-Disk ratio. For workloads with long retention times, the recommended ratio is 1:100. For example, 10 TB of data would require at least 100 GB of RAM. For more user-facing workloads, a ratio of 1:30 to 1:50 is generally recommended.

If in doubt, go with more RAM. Unlike most other hardware changes, adding RAM to a bare metal server is one of the easiest upgrades. It typically requires only a brief maintenance window for a reboot, with no data migrations or configuration changes needed. Our skilled support is available 24/7.

5. SSDs are usually the right answer

For most analytical workloads, SSDs are the default choice, preferably fast NVMe drives. 

HDDs can work, but they require careful load management, mainly due to their limited IOPS capacity. This often forces you to use a large number of disks, which can negate some of the cost savings. 

For tiered storage setups (hot SSD + cold HDD), which ClickHouse natively supports, we recommend caution. While this type of setup can bring some cost savings, we've had operational difficulties managing it.

Although open source ClickHouse supports S3 compatible object storage as a storage backend, it comes with several caveats, including slower merge performance, higher query latency, and the fact that each replica maintains its own full copy of the data in S3, effectively multiplying the required storage by the number of replicas. For these reasons, we only recommend using object storage for cold, infrequently accessed historical data rather than active workloads.

But since every deployment is different, we’ve prepared a set of example starting configurations to serve as inspiration and a practical framework you can adapt to your workload.

6. Example starting configurations

The configurations below are reasonable starting points for self-hosted ClickHouse sizing. Adjust based on your concurrency, retention, and query complexity.

Our Hardware page lists all available options, so you can easily find the configuration that makes the most sense for your workload.

7. Real-world configurations from our deployments

To show how the principles above translate into practice, here are three of our production ClickHouse clusters that each serve a different scale and workload profile. The examples are not meant to be copied directly.

All figures are approximate. Write throughput refers to total rows inserted across all tables, including rows generated by materialized views. Read throughput and QPS (Queries Per Second) are measured across all replicas.

Last but not least…

Choosing the right hardware is only the first step toward a well-performing ClickHouse deployment. If you’re planning your own setup, we combine top-tier dedicated infrastructure and a high-performance global network with our relentless client focus to help you get the most out of it.

You can build your server directly on the Server configuration page.

If your workload has more specific requirements, our team is always happy to help design a setup that fits your needs. Let us know!

In the next part of the series, we’ll move from hardware to actual deployment and walk through practical best practices for bringing a new ClickHouse cluster online so that it stays fast, stable, and is easy to operate from day one.