Dedicated Game Server Specs by Player Count: CPU, RAM, Bandwidth, and NVMe Numbers (2026)

Every “how many players can this server hold” question has an answer, but it is almost never a single number. Player capacity is determined by the game’s threading model, the tick budget it must meet, and the failure mode you consider acceptable when that budget is exceeded. A server that runs a 100-player world at 60 ticks per second with stable per-tick times is a different machine from one that technically holds 100 players while the tick time oscillates between 10 and 90 ms. This guide works through the numbers by genre, gives the measurement method that settles capacity empirically, and maps spec ranges to player counts. For a wider look at how hardware classes map to workloads, see the dedicated hardware reference on this site.

Why capacity is a tick-budget question

Most game servers run a fixed-rate simulation loop. At 30 ticks per second the loop has 33.3 ms per iteration; at 60 ticks per second, 16.7 ms. Within that window the server must process player input, run world simulation, and serialise state to every connected client. As player count grows, the work in each phase grows roughly with the number of entities in proximity — for many games, superlinearly.

Capacity is therefore the player count at which the 99th-percentile tick time approaches the budget. That is the number you should plan around, not the point where the loop visibly fails.

The single-core ceiling nobody mentions

Most game servers — including the common survival titles and many competitive ones — run their world simulation on one main thread. Adding cores past the point where the simulation saturates does nothing for player capacity; it only helps with auxiliary work such as networking threads, save compression, and mod sandboxes.

This is the most important specification insight for buyers. A 16-core CPU at 4.5 GHz will generally hold more players in a single-world survival server than a 32-core CPU at 2.8 GHz, even though the latter costs four times as much. Core count becomes relevant when you run several world instances on one machine.

The practical rule: choose the fastest realistically achievable single-core clock within your power and cooling budget, then add cores to match the number of concurrently hosted worlds, not the player count.

RAM scales with world state, not players alone

Player count is a proxy for world complexity, not a direct driver of memory use. A modded survival world with thousands of loaded chunks and populated containers can consume eight times the RAM of a vanilla world with the same players. Measure the resident set size at your expected load with the map fully explored in the way your players actually explore it.

A planning baseline for the common survival titles: 4–6 GB for a small vanilla world with 10 players, 8–12 GB for a modestly modded 30-player world, and 16–24 GB for heavily modded communities in the 60–100 player range with large explored areas. Add headroom of about 25% so the garbage collector is not running continuously.

ps -o rss= -p $(pgrep -o java) | awk '{printf "%.1f GB\\n", $1/1048576}'
grep -E "VmRSS|VmHWM" /proc/$(pgrep -o java)/status

Storage: write endurance more than speed

Game servers are write-heavy in bursts. World saves, log rotation, and mod updates all produce synchronous writes. A server running 60 players on a map that autosaves every few minutes generates sustained small random writes, which is exactly the pattern that consumes NVMe endurance.

Budget the endurance. A drive rated for 600 TBW writing 20 GB per day lasts just over 80 years, but a heavily modded server with verbose logging and frequent backups can write several hundred gigabytes daily, cutting that life to a couple of years. Use smartctl to read Percentage Used monthly and keep a spare slot in the chassis for a replacement drive.

For capacity planning, two mirrored NVMe drives are the sensible default. RAID 5 with parity is a poor fit for write-heavy small-file patterns because every write incurs a read-modify-write cycle.

Bandwidth per player, by genre

Bandwidth is rarely the binding constraint on a modern connection, but it matters at scale. A rough per-player estimate at peak activity: 30–60 kbit/s for a competitive shooter, 20–40 kbit/s for survival titles with moderate entity density, and 5–15 kbit/s for turn-based or low-frequency simulation. Outbound dominates; inbound is usually a small fraction.

Add 30% headroom for mod downloads and voice chat, which create large short spikes that an average-based estimate misses entirely. A 1 Gbit uplink comfortably supports several hundred players across multiple instances; the network switch and any DDoS scrubbing path are usually the real limits.

Measuring actual capacity on your hardware

Synthetic capacity tables are a starting point, but the only number that matters is the one your server produces. Load test with bots that reproduce realistic input patterns — idle players cost far less than players moving and interacting.

# log tick time each second for ten minutes
while true; do date +%s.%N; sleep 1; done > /tmp/ts.log
# correlate with the server's own tick timing output
sort -n -k2 server_tick_times.txt | awk '{a[NR]=$2} END{print "p50",a[int(NR*0.5)],"p99",a[int(NR*0.99)]}'

Ramp player count in steps of ten, hold each step for five minutes, and record p50 and p99 tick time. The capacity ceiling is the last step where p99 stays below about 70% of the tick budget. That margin absorbs the coincidence of a mob wave, a save, and a player joining in the same tick.

Turning measurements into a purchase

Once you know your single-world player target and how many worlds you need, the specification follows almost mechanically: pick the highest single-core clock you can afford, size RAM to the explored world plus 25%, choose mirrored NVMe with endurance headroom, and add cores only for additional instances. Reserve the rest of the budget for plenty of RAM and a provider with a reliable network path, since those determine the experience far more than an exotic CPU model. Re-measure after any major game update, because a single balance or networking change can shift the capacity ceiling by 20% in either direction. For more capacity and hardware sizing walkthroughs across game genres, see the performance guides on bestdedicatedwebhostingserver.com.