How Much Server Do You Need? Sizing CPU, RAM and Storage by Workload

Answer first: the method

Sizing is three numbers multiplied together, not a guess:

1. Baseline — what the workload consumes under normal load. Measure it if the workload exists anywhere today (a VPS, a staging box, your laptop under load testing); estimate it from the heuristics below if it doesn't.
2. Headroom — multiply by 1.5–2×. Headroom absorbs traffic spikes, background jobs, and the performance cliff every system hits near saturation (a database at 90% RAM behaves much worse than one at 60%, not 30% worse).
3. Growth — project over the commitment term, not launch week. If data grows 10 GB/month, a year needs 120 GB more than today.

And one framing rule that prevents the most expensive category of mistake: size RAM and storage generously, CPU moderately. An underprovisioned CPU makes things slower; insufficient RAM or full disks make things fail. CPU is also the resource workloads most often overestimate — most servers idle most of the time — while RAM is the one they most often underestimate.

If you just want defaults, here are honest starting points; the rest of the article is the reasoning to adjust them:

CPU: cores versus clocks

The core-count arms race obscures the question that matters: is your workload parallel or serial?

• Parallel workloads — virtualisation, CI, video encoding, request-heavy APIs — scale with core count. Buy cores.
• Serial workloads — game-server ticks, single-threaded application loops, many database query paths — are bounded by single-core speed. Buy clocks (and newer microarchitecture), not cores; sixty-four slow cores lose to eight fast ones, and this is the single most common game-server sizing mistake.
• Mixed reality: a web stack is parallel across requests but each request is serial — so mid-range core counts with strong per-core performance fit best, which is why that's the sweet spot most web workloads land on.

Practical notes: hyperthreads are not cores (count them as ~+20–30% throughput, not ×2); virtualisation hosts can oversubscribe CPU meaningfully (guests rarely peak together — the ×0.7 in the table), but should never oversubscribe RAM.

RAM: the resource you'll regret skimping on

Rules of thumb that hold up:

• Databases: the working set — the data actually touched regularly — should fit in RAM, with room to spare. The single biggest database performance lever is not query tuning, it's whether reads come from memory or disk. Estimate hot set (often 10–30% of total data), add indexes, multiply by 1.5.
• Virtualisation: RAM is the binding constraint on VM density in almost every real deployment — hosts run out of memory long before CPU. Sum your guests' allocations, add 4–8 GB for the host (more if ZFS: its cache will happily and usefully consume what's spare).
• Web/app: application processes × per-process footprint, plus opcode/object caches, plus OS file cache (which is why "unused" RAM speeds up your disk reads — Linux uses every idle gigabyte as cache).
• The failure mode to avoid is swapping under load: when RAM runs out, performance doesn't degrade gracefully — it falls off a cliff while the disk thrashes. If monitoring shows any sustained swap activity under normal load, the box is undersized today, not soon.

Storage: capacity is the easy half

• Capacity: current data × growth over the term + 30% slack (full disks corrupt databases and block deploys at the worst moments). Then apply the RAID overhead — usable capacity is not raw capacity, and the difference is the topic of our RAID levels guide: mirrors halve it, parity costs one drive.
• Performance: for anything latency-sensitive (databases, VM stores, busy web apps) the answer in 2026 is NVMe, full stop — the random-I/O gap versus SATA SSDs is large and versus HDDs is categorical. Spinning disks retain exactly one role: cheap bulk capacity for media, archives, and backup targets, ideally behind an NVMe layer for the hot path.
• Endurance: write-heavy workloads (databases with churn, CI scratch, video ingest) consume SSD write endurance. It's rarely a problem at typical intensities, but if you expect to rewrite multiple terabytes daily, mention it when specifying — datacentre-grade drives with higher endurance ratings exist for exactly this.

Bandwidth: arithmetic, not vibes

Convert between monthly volume and sustained rate with one factor: 1 TB/month ≈ 3 Mbit/s sustained average. So a 1 Gbit/s port, saturated flat-out, moves ~330 TB/month — which tells you immediately that most workloads are nowhere near port-limited on volume. What actually decides the network spec:

• Peaks, not averages. Traffic is bursty; a site averaging 30 Mbit/s can spike to hundreds during a launch. Port speed buys burst absorption.
• East-west traffic — replication, backups, storage sync between your own servers — is where 10 Gbit/s earns its keep long before public traffic does. (Backup-window math: restoring 4 TB over 1 Gbit/s takes ~9 hours; over 10 Gbit/s, under one. Size the port for the restore you'll one day be sweating through.)
• Latency is a location-and-network property, not a port-speed property — game servers and real-time apps should pick datacentre proximity and network quality first (this is where running on a host's own well-peered ASN matters more than the port number).

Scale up or scale out?

When you outgrow a box, there are two directions, and the right one depends on the workload's shape:

Scale up (a bigger server) while you can: it's operationally free — no code changes, no distributed-systems tax — and dedicated hardware goes a long way up before you hit its ceiling. Databases especially prefer this path; distributed databases are a last resort, not a growth plan.

Scale out (more servers) when the workload divides naturally: stateless web/app tiers behind a load balancer (also your redundancy story — two medium boxes beat one big one the day one of them needs a reboot), game-server instances by region, CI runners by queue. The classic first split is moving the database to its own machine — one migration, and both tiers get a dedicated resource profile matched to what they actually need (the web tier's cores, the database's RAM and NVMe).

Frequently asked questions

How much RAM does my database really need?

Work from the hot set, not the total: a 500 GB database whose queries touch 50 GB of rows and indexes day-to-day performs beautifully with 96 GB of RAM and miserably with 16 GB — while a rarely-queried 2 TB archive can live happily on far less than its size suggests. Find the hot set empirically where possible (cache-hit ratios in pg_stat/InnoDB metrics on your existing system), add indexes and 50% slack, and re-check yearly — hot sets grow.

Do I need a 10 Gbit/s port?

For public traffic, probably not — 1 Gbit/s moves ~330 TB/month flat-out, far beyond most sites. The workloads that genuinely want 10 GbE are inter-server: database replication, VM migration, distributed storage, and above all backup/restore windows (a multi-terabyte restore at 1 Gbit/s is an all-day incident; at 10 Gbit/s it's a coffee break). If your architecture includes any always-on data shuttling between machines, spec it; otherwise spend the difference on RAM.

Should I overprovision now or upgrade later?

Overprovision the things that are disruptive to change — RAM and storage, where an upgrade means downtime and a maintenance window — and buy CPU closer to measured need, since it's the component least often exhausted in practice. The 1.5–2× headroom rule already builds in a year of comfortable growth for a typical workload; beyond that, honestly assess how painful a migration would be for this system. Stateless tier? Cheap to move, buy lean. Stateful database? Expensive to move, buy roomy.

When do I actually need a dedicated server rather than a VPS?

When any of these become true: sustained CPU or I/O load that shared platforms throttle or bill punitively; a RAM requirement (64 GB+) where dedicated pricing beats equivalent VPS tiers; latency sensitivity that can't tolerate noisy neighbours; or the need for full hardware control — hypervisors, custom kernels, raw NVMe. Spiky, mostly-idle workloads remain the VPS's home turf; steady, performance-sensitive ones cross over surprisingly early. Our distro guide's bare-metal section covers this boundary in more depth.

Deploying on Serverside

The method translates directly into our dedicated server configurator: pick per-core-fast or many-core CPUs to match your workload's shape, size RAM and NVMe with the headroom rule, and see RAID's usable-capacity arithmetic applied live as you choose drives. Every configuration lands on our own ASN 55285 network — well-peered, with always-on DDoS mitigation — and provisions in under a minute, which also makes the "start reasonably, resize by redeploying" strategy genuinely practical.

Once it's ordered: the first-hour hardening checklist, and if the plan involves slicing the box into VMs, our Proxmox guides take it from there.