How to Spec Two ClickHouse Servers for 5 TB of Data Growing 500 GB a Month

By Ordinal Science · 2026-10-14

Buying hardware for an analytics database is a balancing act. Buy too little and you hit limits within a year. Buy too much and you have expensive machines sitting idle. This article walks through how we would spec two physical servers for ClickHouse. The starting point is about 5 terabytes of data, with roughly 500 gigabytes of new data arriving each month.

We will focus on the parts that matter most: storage, memory, and processing power. We will also cover a few smaller details that are easy to miss.

Start with the growth numbers

Before choosing any parts, it helps to do some simple maths. At 500 GB a month, you add about 6 TB a year. After three years, you could be looking at around 23 TB in total.

There is one important question to answer first. Are those figures the raw size of the data, or the size it takes up inside ClickHouse once compressed?

ClickHouse stores data in columns and compresses it well. Raw data often shrinks a lot once loaded. It is common to see compression ratios somewhere between 3 to 1 and 10 to 1, so 5 TB of raw data might take up only 500 GB. But how much depends on your data. Repetitive logs compress very well, sometimes beyond 10 to 1. Random IDs and free text do not. Do not rely on a rule of thumb here. Load a representative sample, perhaps a month of data, and check the compressed size. That one test will shape the rest of your plan.

If the 5 TB is raw data, your real footprint may be much smaller and the storage budget gets easier. If the 5 TB is already the compressed size, you need to plan for the full growth curve.

Why two servers?

Two servers give you redundancy and room to share the load. The usual approach is to keep a full copy of the data on each server using ClickHouse replication. If one machine fails, the other keeps serving queries. You can also spread queries across both.

There is one catch. Replication relies on a coordination service called ClickHouse Keeper. Keeper needs a majority to agree before it acts. With only two members, losing one means no majority. So plan for a third Keeper instance. This does not need to be a big machine. A small virtual machine or a modest spare box will do. It only coordinates. It does not store your data.

Replication is also not a backup. If someone drops a table or loads bad data, that change copies to both servers. Keep separate backups, for example in object storage.

Storage: NVMe first

ClickHouse reads large amounts of data quickly. Storage speed has a direct effect on query times, and on how fast new data is merged in the background. This is why NVMe drives are the right choice for your main data.

A few things to look for:

Choose enterprise or data centre NVMe drives, not consumer ones. They are built for constant heavy use.

Check the endurance rating. This is often given as drive writes per day. ClickHouse writes data, then merges it into larger pieces, which means extra writes. We recommend one or more full writes per day as a baseline.

We also recommend power loss protection. This helps protect data that is in flight if the power cuts out.

Keep the operating system on separate drives. A pair of small mirrored SSDs is enough. We mirror these even though we suggest no RAID for the data drives. A failed OS drive takes down the whole server, while replication already protects the data. This setup also keeps system activity away from your data drives.

Plan for free space. ClickHouse needs spare room to merge data in the background. If disks run too full, merges slow down or fail. We aim to keep data disks well below 80 percent full.

As a starting point, consider four to six 7.68 TB NVMe drives per server. We recommend using them as plain disks, without RAID, and relying on replication between the two servers for protection. Some published guides for multi-replica setups favour this approach. ClickHouse's own RAID advice only covers hard drives, not NVMe.

Without RAID, four to six drives give you about 30.7 to 46 TB per server. Four drives at 80 percent full leave about 24.6 TB, which just covers the 23 TB three-year projection. That is only about three months of headroom at 500 GB a month, before allowing for merge space. If the 5 TB is already compressed, five or six drives is the safer starting point.

There is a trade-off. If a disk fails, the data parts on it are lost from that server. You run on one copy until those parts are fetched back from the other server. So monitor your disks and keep a spare on hand.

If you choose RAID 10 instead, the same drives give roughly 15 to 23 TB usable. With six drives, the 80 percent ceiling is about 18.4 TB. That is below the 23 TB projection, so tiered storage stops being optional.

Most importantly, pick a chassis with empty drive bays. Starting with four drives and room for eight is far cheaper than replacing the whole server later.

Use tiered storage to avoid overspending

Not all data needs to live on fast drives. Most analytics queries focus on recent data. Older data is read less often.

ClickHouse supports tiered storage. You can set rules so that data older than a set period moves automatically to cheaper storage. That might be large hard drives in the same server, or object storage. Recent data stays on NVMe. Older data still remains queryable, just a bit slower.

This is one of the best ways to control cost. It means your NVMe capacity only needs to cover your "hot" window, such as the last six or twelve months, rather than your full history.

Memory: generous, with room to grow

ClickHouse uses memory for query processing, caching, and merges. Queries that group or join large datasets can use a lot of it. When memory runs short, queries fail or spill to disk and slow down.

For this data size, 256 GB of RAM per server is a sensible starting point. ClickHouse's own guide suggests a memory-to-storage ratio of about 1:100 to 1:130 for large retained datasets. At the 23 TB projection, 1:100 points to around 230 GB. Customer-facing workloads need more, at around 1:30 to 1:50. Make sure the motherboard has free slots so you can grow to 512 GB later without swapping out existing modules. We also recommend ECC memory, which detects and corrects small memory errors. For a database server, we would not go without it.

It is also worth setting memory limits inside ClickHouse. This stops a single heavy query from taking all the memory and affecting everyone else.

Processing power: cores matter

ClickHouse splits queries across many CPU cores at once. More cores usually means faster queries, especially for large scans. Clock speed matters too, but core count tends to give the bigger gain.

A single-socket server with 32 cores is often the right target. Modern server CPUs offer high core counts on one socket. This keeps the design simpler and often cheaper than a two-socket machine. If your workload turns out to be heavy, choose a platform that also supports higher core count chips, so an upgrade is possible later.

One caution. ClickHouse does not reshard data automatically, and resharding later is costly. For that reason, some sizing advice suggests buying the largest servers available. We take a more modest line, which is why we stress room to grow inside each server.

Do not forget the network

Two servers replicating data need a fast link between them. New data arrives on one server and copies to the other. 10 gigabit networking is the minimum. We recommend 25 gigabit, as the cost difference is often small and it gives you headroom for replication, backups, and recovery.

A sample spec per server

Pulling this together, a balanced starting point for each server might look like this. It assumes the 5 TB is already the compressed size.

A single-socket CPU with 32 cores.

256 GB of ECC memory, with free slots to reach 512 GB.

Two small mirrored SSDs for the operating system.

Five or six 7.68 TB enterprise NVMe drives for data, without RAID, with spare bays.

Optional large hard drives or object storage for older data.

Dual 25 gigabit network ports.

Redundant power supplies.

Plus a small third machine or virtual machine to run ClickHouse Keeper, and a separate backup target.

A final word

The aim is not to buy for year five on day one. It is to buy a solid base that can grow in steps. Spare drive bays, empty memory slots, and tiered storage let you add capacity when the data actually arrives.

Test your compression ratio early. Watch disk usage and memory use once you are live. Those numbers will tell you when the next upgrade is due, so you are not guessing.