If you are trying to work out what specs a Minecraft server needs, most of the advice you will find leads with RAM and stops there. That is the wrong end of the problem. This post is a plain, honest reference for what actually decides whether a server runs well: single-thread CPU speed and cache first, then enough RAM to be comfortable, then fast storage for the world. It gives rough guidance by player count and server type, and explains why two servers with the same RAM figure can feel completely different to play on.

The one thing that matters most: single-thread CPU

A Minecraft server runs its main work on a single thread. That thread has to finish everything for the current tick (entities, redstone, block updates, player actions) before the next tick starts. The target is twenty ticks per second, which is fifty milliseconds per tick. If that one thread cannot finish in fifty milliseconds, your TPS drops and the game feels slow, no matter how many cores the box has spare.

So the CPU spec that counts is how fast a single core runs one thread, set by clock speed and IPC, and how rarely that core has to stop and wait on memory, which is set by cache. A game tick spends a lot of its time chasing data around memory, and every time the data it needs is not in cache the core stalls and waits. More cache means fewer stalls, which is why large-cache chips do so well on this workload. The full argument, including why extra cores help less than people expect, is in choosing a CPU for Minecraft.

RAM is capacity, not speed

RAM decides how much your server can hold at once: loaded chunks, entities, and the plugins or mods kept in memory. It does not make the tick run faster. A server needs enough RAM that the JVM is not constantly garbage-collecting and never swapping to disk, and past that point more gigabytes sit idle and do nothing for performance.

This is where the RAM-first advice goes wrong. A server starved of memory does stutter, so adding RAM to a starved server helps, but a server that already has enough gains nothing from more. We work through sizing properly, including why an oversized heap can actually make pauses worse, in how much RAM a Minecraft server needs.

Storage: NVMe for chunk I/O

Storage matters for a narrower reason than CPU or RAM. When a player sprints into unexplored terrain, the server reads and generates chunks and writes them back, and it saves the world periodically. Those reads and writes are latency-sensitive, and slow storage can stall the tick while it waits on the disk. Gen4 NVMe keeps that latency low enough that the tick rarely waits, where a cheap SATA SSD or a shared spinning disk can hitch under a busy world. For most servers storage is not the bottleneck, but it becomes one fast on a big or heavily explored world.

Rough guidance by server type and size

These are starting points, not laws. Plugin and mod count, view distance, world size and how much your players build all move the numbers, so watch real usage rather than trusting any table blindly. RAM figures here assume it is reserved and genuinely available, not a shared limit on an oversold box.

  • Small vanilla or friends server, a handful of players: modest single-thread CPU, around 2 to 4GB RAM, NVMe preferred.
  • Plugin SMP (Paper or a fork), a few dozen players: strong single-thread CPU matters here, around 4 to 8GB RAM.
  • Large community, many plugins and a big world: the fastest single-thread CPU you can get, around 8 to 12GB RAM, sometimes more, and NVMe becomes important for chunk I/O.
  • Heavy modpack: modpacks are the hungriest case, wanting around 8 to 16GB RAM or beyond because mods load far more into memory, and they lean hard on single-thread CPU because each tick does more work.

The RAM figures are starting points for how much to reserve, not a measure of how well the server will run. Single-thread CPU speed and cache decide that. Once the heap is large enough to keep the JVM from garbage-collecting hard or swapping, more RAM sits idle, so size it to be comfortable and spend the rest of your budget on the CPU.

Player count is only half the story. Twenty players standing in a lobby cost almost nothing. Twenty players spread across the world, each loading chunks and running farms in different directions, cost a great deal, because the server has to simulate all of it at once. Size for what your players actually do, rather than for the headcount alone.

Why two servers with the same RAM perform differently

This is the question that catches people out. Two servers both listed as "8GB" can play completely differently, and RAM is rarely the reason. A few things explain the gap.

The CPU underneath is the big one. An 8GB plan on a fast, large-cache chip that you are not sharing will out-tick an 8GB plan on a slow or heavily shared core every time, because the tick thread is where the game actually spends its time. The RAM figure is identical and the experience is not.

Whether the resources are reserved is the next factor. On an oversold node your "8GB" is a limit on paper, shared with neighbours who might all get busy at once, and when they do your server is squeezed onto whatever is left and starts swapping. Reserved RAM and reserved cores mean the number on your plan is the number in the machine when you need it. We cover how to spot the difference in spotting overselling in game hosting.

The software stack accounts for the rest. A server running a well-tuned performance fork with a sensible config and a lean plugin list will carry far more on the same hardware than one running stock software with a heavy, half-used plugin set. Same RAM, same CPU, very different result, decided entirely by what you run and how it is configured.

The short version: buy single-thread CPU and cache first, buy enough reserved RAM to be comfortable and no more, put the world on NVMe, then tune the software. The pillar guide to running a Minecraft SMP walks that whole chain in order, from the box up to the last plugin.

A note on these numbers against reality: most servers clear them comfortably, and the care we take above them is overkill for a small world. Buying the headroom once is simply cheaper than discovering you needed it on a Friday evening.

If you want hardware chosen around these priorities without assembling it yourself, our Minecraft hosting runs high-clock, large-cache parts with reserved cores and RAM for exactly the reasons above.