Game Server Sizing: Where CPU, RAM and NVMe Run Out at 50, 100 and 200 Players

A game server runs out of a single resource before the others, and the identity of that resource changes with player count. At 20 concurrent players a €60 VPS with four shared vCPUs and 8 GB of RAM is comfortable. At 200 players the same workload needs a 4.5 GHz-class core that is never stolen, 24–32 GB of resident memory and an NVMe device that keeps write latency under 1 ms during autosaves. This article maps where each budget closes first, using measured data from survival, sandbox and source-engine titles, so sizing decisions rest on numbers rather than the “recommended” column of a store page.

The Four Budgets That Decide Player Capacity

Every game server consumes four budgets simultaneously: single-thread CPU time per tick, resident memory, storage write latency during saves, and outbound bandwidth. Whichever budget is smallest in relative terms limits the slot count. Widening one budget without widening the others simply moves the bottleneck — doubling RAM on a CPU-bound server produces a longer uptime with identical tick spikes.

Budget	Unit of consumption	Typical close-out point	Symptom when exhausted
Single-thread CPU	ms of tick budget	100–170 players (FPS/sandbox)	Tick rate drops, rubber-banding
Resident memory	GB per 10 players	40–90 players on modded worlds	OOM kill or heavy GC pauses
NVMe write latency	ms at queue depth 1	Save cycles above 2 GB	Freeze spikes every autosave
Outbound uplink	Mbps per player	80–120 players at 1 Gbps	Client packet loss, lag spikes

CPU: The Tick Loop Is Single-Threaded

At a 60 Hz tick rate the loop has 16.6 ms per tick. Entity replication is the dominant cost: budget roughly 0.06–0.12 ms per connected player once per-client visibility filtering and snapshot delta encoding are included. At 0.08 ms, 140 players consume 11.2 ms, leaving 5.4 ms for physics, AI and script execution. That margin disappears at 170 players, and the tick rate does not crash — it slides to 34–40 Hz and clients render the deficit as stutter.

Core choice matters more than core count. A Ryzen 7 7700 at 5.3 GHz boost will hold a 100-player sandbox world that an older 16-core Xeon Silver 4310 cannot, because the Xeon settles near 2.9 GHz under sustained load. Practical ranking for 2026 game nodes: Ryzen 9 7950X (5.7 GHz boost), Core i9-14900K, Ryzen 7 7700, then EPYC 4004 series at 4.5 GHz. When core count is the dominant requirement — many instances per box — prefer EPYC 9354P class parts and accept the lower clock, then cap each instance to 60 slots to stay inside the budget.

Virtualization adds a second variable: CPU steal. Shared plans with a 3:1 vCPU oversubscription show steal spikes of 4–15% exactly when a world save or mod scan runs. Anything above 64 slots needs committed cores with no ballooning, which is the difference between a dedicated server with published clocks and committed cores and a nominally identical VPS plan.

Memory: Where the Real Multiplier Sits

Vanilla Minecraft with 10 players sits near 2.5 GB resident. A 200-mod Forge pack with the same population sits at 11–14 GB, and memory climbs another 1.2–1.8 GB per additional 20 players because chunk and entity caches grow. Palworld, Valheim and Enshrouded follow similar curves: 4 GB baseline, plus roughly 30–60 MB per player, plus a fixed per-mod allocation.

• Vanilla survival: 4 GB for up to 30 players, 8 GB for up to 60.
• Modded (Forge/NeoForge 200+ mods): 12 GB for 20 players, 20 GB for 50.
• Palworld dedicated: 8 GB for 8 players, 16 GB for 32.
• Rust with 150-slot pop: 16–24 GB depending on entity count after wipe.
• ARK ASA cluster node: 12–16 GB per map plus 2–4 GB for the transfer data cache.

Memory speed is not a tuning detail either. DDR5-5600 in dual channel delivers roughly 85 GB/s; DDR4-2666 in quad channel delivers 55 GB/s. The gap shows up as a 6–11% improvement in tick stability on large AI populations, because pathfinding iterations and entity transforms are memory-latency bound.

Storage: Save Cycles Are the Hidden Spike

Sector writes are the metric that matters, not sequential throughput. A 3 GB world save written in 2 MB chunks needs around 1,500 sequential operations, which any SATA SSD handles. Concurrent autosaves across four instances plus log flush produce thousands of random 4K writes, and that is where consumer NVMe drives fall to 300–800 µs of queue-depth-1 latency and produce visible freezes.

Player count	World size	Required NVMe class	Save freeze target
Up to 50	1–3 GB	Consumer NVMe acceptable	< 400 ms
50–120	3–10 GB	Enterprise NVMe with PLP	< 250 ms
120–200	10–25 GB	Enterprise NVMe, RAID 1 recommended	< 150 ms
Any, 4+ instances	25 GB+	Tiered drives or NVMe RAID 10	< 100 ms per instance

Bandwidth: 1 Gbps Is Enough Until It Isn’t

Average per-player throughput is modest — 40–90 kbps for a survival title, 120–200 kbps for a 64-tick shooter with voice chat. The peak multiplies during mod downloads at login and during snapshot-heavy moments. Budget 2.5–3 Mbps per player at peak if the server hosts workshop content, which puts 150 players at 375–450 Mbps and comfortably inside a 1 Gbps port with 95th percentile billing.

Putting the Three Counts Together

A realistic 2026 configuration matrix, priced against current market rates on bare metal:

Target	CPU	RAM	Storage	Uplink	Monthly cost
50 players, vanilla/modded survival	Ryzen 5 3600 6c/12t	16 GB	512 GB NVMe	1 Gbps / 10 TB	$55–75
100 players, source-engine shooter	Ryzen 7 5800X	32 GB	1 TB NVMe	1 Gbps unmetered	$90–120
150 players, Rust or sandbox	Ryzen 9 5950X	64 GB	2 TB NVMe	1 Gbps unmetered	$140–190
200 players, clustered worlds	Ryzen 9 7950X	64 GB ECC	2x 2 TB NVMe RAID 1	2 x 1 Gbps bonded	$200–280
Multi-instance host, 8 nodes	EPYC 9354P 32c	256 GB ECC	4 TB NVMe	10 Gbps	$500–700

Cost per slot lands between $0.90 and $1.60 on these configurations. A hosting plan that advertises 200 slots for $35 per month is either oversubscribing the CPU by a factor of six or counting slots that will never be online at once. Before committing, test the node rather than the sheet: run a 15-minute sustained single-thread load and check effective clock, then verify the write latency at queue depth 32. Providers who publish those figures can be compared side by side on the main site and shortlisted without a sales call.

For anything past 200 concurrent players, the answer stops being a bigger box. Sharding by region or by world, with a proxy layer holding persistent player state, spreads the CPU budget across nodes and keeps each tick loop inside its deadline. That architecture costs roughly 1.3–1.5 times a single large node but removes the single-thread ceiling that no amount of RAM will fix.