ClickHouse on a dedicated server: sizing cores, RAM and NVMe

ClickHouse runs best on a dedicated server with many fast cores, enough RAM to keep recent data in the page cache, and NVMe for merges and cold scans. A single EPYC 9254 with 24 cores, 128 GB of DDR5 and NVMe storage is a strong first node, and a replica on a second server adds failover.

This guide sizes each part with worked numbers, shows the compression arithmetic, explains when one node is enough and when a cluster earns its complexity, and marks the point where a VPS stops being the right home for an analytics database.

What does ClickHouse need from a dedicated server?

ClickHouse is an open source, column oriented database for analytics. It stores each column separately, compressed, and answers a query by reading only the columns it needs and processing them in large blocks across every core. That design decides the hardware: it rewards cores, memory bandwidth and fast disks, in roughly that order for typical dashboards and reports.

Most tables use the MergeTree engine. Inserts land as small sorted parts, and background merges combine them into larger ones. A sparse primary index, one entry per 8,192 rows by default, lets a query skip the parts and ranges it does not need. Merges and skipping both shape how much CPU, RAM and disk you need.

How many cores and how much RAM does a ClickHouse server need?

Cores for parallel scans

ClickHouse parallelises a single query across cores. Its max_threads setting defaults to the number of physical cores, so a scan that is CPU bound finishes faster on a machine with more of them, as long as memory and storage keep up. Background merges also take CPU, so leave room for them during busy ingest.

• 24 cores (single EPYC 9254) suit most single node deployments: dashboards, product analytics and log search for one company.
• 48 cores (dual EPYC 9254) help when many users run heavy queries at once, or when ingest and merges compete with queries all day.
• 128 cores (dual EPYC 9554) are for very large scans and a lot of concurrency on one node.

Clock speed still matters. Some stages of a query run on fewer threads than the scan, so fast cores shorten every query, not only the large ones. That is why the 2.9 GHz base and 4.15 GHz boost of the EPYC 9254 fit ClickHouse well. Our EPYC 9254 guide covers the processor in detail.

RAM for queries and the page cache

RAM does two jobs. It holds the working memory of queries, mostly hash tables for GROUP BY and the right hand side of joins. And the operating system's page cache keeps recently read column files in memory, so repeated dashboard queries skip the disk.

Size the page cache to your hot data. As an example, take 15 GB of raw event data a day that compresses 6:1 (an assumption, see below). Dashboards that look at the last 30 days touch 30 × 15 GB = 450 GB of raw data, which is 75 GB on disk. On a 128 GB server that hot month fits in the page cache with room left for query memory. On the dual EPYC 9254 with 256 GB, three months would fit.

Query memory is the other half. A GROUP BY over millions of distinct keys builds a large hash table. When a query needs more memory than its limit, ClickHouse stops it with a memory limit error, unless you let it spill to disk with max_bytes_before_external_group_by. Spilling works, but it is slower and puts load on the disks. More RAM is the cleaner fix for regular heavy queries.

How do you work out ClickHouse storage? The compression math

Columnar storage compresses well because each column holds values of one type, often sorted and repetitive. ClickHouse uses LZ4 by default, with ZSTD for a better ratio at more CPU, and special codecs such as Delta, DoubleDelta, Gorilla and T64 for timestamps, counters and metrics.

The ratio depends entirely on your data, so measure it rather than trusting a quoted figure. Once you have a sample loaded, this query gives the real ratio per table:

SELECT table,
       formatReadableSize(sum(data_compressed_bytes)) AS on_disk,
       formatReadableSize(sum(data_uncompressed_bytes)) AS raw,
       round(sum(data_uncompressed_bytes) / sum(data_compressed_bytes), 1) AS ratio
FROM system.parts
WHERE active
GROUP BY table
ORDER BY sum(data_compressed_bytes) DESC;

A worked example

Here is the arithmetic for an example workload. All inputs are assumptions you should replace with your own.

Step	Calculation	Result
Raw data per day	100 million events × 150 bytes	15 GB
Raw data per year	15 GB × 365	5,475 GB, about 5.5 TB
On disk at an assumed 6:1	5,475 GB ÷ 6	912.5 GB, about 0.9 TB
With room for merges and growth	0.9 TB × 2	about 1.8 TB

The doubling is deliberate. A merge writes the new part before it deletes the old ones, so the disk needs free space at least as large as the biggest merges, and data rarely grows more slowly than planned. A replicated cluster stores every byte once per replica, so two replicas need 1.8 TB each.

Why NVMe

Cold queries that read beyond the page cache, and merges that rewrite parts, are disk bound. NVMe serves many parallel reads at high throughput, which is what a scan across 24 or 48 threads asks for. SSDs work for colder data and larger capacity at a lower price per terabyte.

Which server and disk layout fits a ClickHouse node?

These configurations cover most ClickHouse deployments. Prices are monthly with the 1 Gbps guaranteed unmetered port and exclude VAT. Usable capacity assumes RAID 10, half the raw capacity.

Configuration	Cores	RAM	Storage	RAID 10 usable	Per month
Single EPYC 9254	24	128 GB DDR5	2 × 1 TB NVMe	1 TB (mirror)	€449
Single EPYC 9254 + 24 × 1 TB NVMe	24	128 GB DDR5	24 TB NVMe	12 TB	€969
Single EPYC 9254 + 24 × 1.98 TB NVMe	24	128 GB DDR5	47.52 TB NVMe	23.76 TB	€1,269
Dual Xeon E5 2699 v4 + 6 × 2 TB SSD	44	256 GB DDR4	12 TB SSD	6 TB	€419
Dual Xeon E5 2699 v4 + 6 × 8 TB SSD	44	256 GB DDR4	48 TB SSD	24 TB	€1,097

For the worked example, 1.8 TB needs more than the included mirrored 1 TB, so the Single EPYC 9254 with 24 × 1 TB NVMe gives years of headroom on fast storage. If the data is large but mostly cold, the Dual Xeon E5 2699 v4 with six SSDs holds more terabytes per euro, with 256 GB of RAM for the page cache. The trade is older cores and DDR4 memory bandwidth.

Some teams running two replicas skip RAID and let ClickHouse use each disk directly through a storage policy, with the second replica as the redundancy. That gives more usable space, at the cost of a resync from the other replica when a disk fails.

One socket or two?

A single ClickHouse process spreads its threads over the whole machine. On the Dual EPYC 9254, part of that memory traffic crosses between sockets, which costs some efficiency per core but still adds a lot of total throughput and doubles RAM to 256 GB. Our guide to single and dual socket servers explains the trade, and the only reliable answer for your queries is a test on both.

Single ClickHouse node or a cluster?

Start with one node. A single well sized server answers a surprising amount of analytics, and it has no coordination layer to operate. Add more servers for one of two reasons.

• Availability. Two servers with ReplicatedMergeTree tables keep a full copy each, so either can answer queries if the other is down. Replication needs ClickHouse Keeper, which runs as three nodes so a majority survives one failure. Two Keeper nodes can sit on the ClickHouse servers and the third on a small VPS close by.
• Scale. When one node's disks or cores cannot hold the data or the query load, split tables into shards across servers and query them through a Distributed table. Sharding adds operational work, so reach for it after you have outgrown the largest single node you are willing to pay for.

Treat replication as availability, not as backup. A dropped table or a bad mutation replicates to every replica. Keep backups with ClickHouse's BACKUP command on separate storage, ideally on another server.

When does a VPS stop being enough for ClickHouse?

A VPS is a fine place to start: development, a proof of concept, or a few tens of gigabytes of compressed data. Our largest KVM VPS plan, Titan, has 8 vCPU, 32 GB of RAM and 120 GB of SSD from €64 a month, with up to 150 GB of extra storage as an option. Our guide to database servers on a VPS covers sizing at that scale.

Move to bare metal when you see any of these:

• Queries slow down at busy hours with no change on your side, and CPU steal shows up in top or sar. Analytical scans use every vCPU at once, so they feel contention on a shared host first.
• Memory limit errors on regular queries, or the page cache can no longer hold the data your dashboards read.
• The disk is the ceiling, either in size or in the rate merges and cold scans can read and write.
• Ingest is network bound. VPS ports are shaped by plan at 100 to 300 Mbps, against a guaranteed 1 Gbps port on every dedicated server.

The database servers use case covers the move from VPS to bare metal for other database engines too.

Questions people ask

Is ClickHouse free to run on my own server?

Yes. ClickHouse is open source under the Apache 2.0 licence, and you can install it on any Linux image from our checkout. The commercial cloud service from the same company is a separate product you do not need.

Can ClickHouse run on the same server as PostgreSQL?

It can, and small teams often start that way. The two compete for page cache and disk bandwidth, so once analytics queries start to slow the application database, give ClickHouse its own server.

Which ports does ClickHouse use?

The HTTP interface listens on 8123 and the native protocol on 9000 by default. Restrict both to your application servers and analysts in the firewall, and never leave the default user without a password on a public address.

How much does a ClickHouse dedicated server cost?

From €449 a month for the Single EPYC 9254 with 2 × 1 TB NVMe, or €969 with 24 × 1 TB NVMe, excluding VAT. For large, mostly cold datasets, the Dual Xeon E5 2699 v4 with six 8 TB SSDs costs €1,097.

Next step

Load a representative sample, run the compression query above, and plug your own numbers into the worked example. Then pick the node from the table: the EPYC 9254 page has the full specification, and EPYC servers are built to order, with a delivery estimate of about 14 days.