How Much RAM Does Your Server Need?
Answer a few quick questions and get three plans sized for your setup.
What Will You Run?
Everything that follows adapts to this answer.
What Your RAM Actually Pays For
On Java Edition the number you pick is the JVM heap size. Loaded chunks, every entity inside them, block entities such as chests and hoppers, and your mod or plugin state all live in that heap.
It is not a speed dial. RAM decides how much world the server can hold in memory at once, and nothing else.
Inside the heap: Forge / NeoForge
20 concurrent players, illustrative split of what occupies memory
10GB used6 GB floor + 0.2 GB × 20 playersThe floor is what Forge / NeoForge needs with nobody online. Everything above it is world data your players pull in, then we round up to the nearest plan we sell, the 12 GB one.
rounds up to the 12 GB plan
- Server jar + JVM
3 GBServer jar + JVM · 3 GBThe Forge / NeoForge jar plus everything the JVM keeps for itself. It costs the same at one player as it does at 20, so it is the part you cannot tune away.
Fixed cost before anyone joins: the engine and its runtime.
- Mods / plugins loaded
3 GBMods / plugins loaded · 3 GBTypical for Forge / NeoForge: every mod or plugin is loaded and held before the first player connects. Doubling your list moves this number, doubling your players does not.
Resident from boot. Grows with the list, not the player count.
- Loaded chunks
2.5 GBLoaded chunks · 2.5 GBRoughly 62% of the 4 GB your players add (0.2 GB per player × 20 players). Players exploring in opposite directions each hold their own chunks, so this is the part that spikes.
One column per player, more when they spread out.
- Entities & block entities
1.5 GBEntities & block entities · 1.5 GBThe other 38% of the 4 GB your players add (0.2 GB per player × 20 players). Mob farms and dropped item piles push it up well beyond the average.
Mobs, items and every chest or hopper in a loaded chunk.
Loaded chunks
Each player pulls their own column of chunks into memory. Two standing together cost far less than two exploring in opposite directions.
Entities inside them
Mobs, dropped items, minecarts and every chest or hopper stay resident for as long as their chunk is loaded.
Code loaded alongside
Your mod or plugin list is resident before anyone joins. Five performance mods and two hundred content mods are not the same server.
- on time
- overran, never caught up
Plenty of free RAM, and the server still lags.
Tick processing is largely single threaded. Once the world takes longer than 50 ms to tick, the server falls behind no matter how much memory is spare.
That is a CPU and world-design problem, not a memory one. Read the tick graph before the memory graph.
RAM by Server Type
Same world, five different engines. Set your player count above and every floor moves with it. Open a row for the detail.
The official server jar with no optimisations. It is the least efficient way to run Java Minecraft, so treat 4 GB as a floor rather than a comfortable number once you pass a handful of players. Sized here at 6 GB for 20 concurrent players.
Paper reuses vanilla logic more efficiently and gives you configuration control over entity limits, chunk loading and view distance. A Paper server will usually hold more players on the same RAM than vanilla will. Sized here at 6 GB for 20 concurrent players.
Fabric itself is light. What costs memory is the mod list on top of it. A Fabric server running only performance mods can sit near vanilla usage; one running 200 content mods cannot. Sized here at 8 GB for 20 concurrent players.
Forge and NeoForge carry more overhead than Fabric before a single content mod loads, which is why almost every large modpack ships on one of them and why their floors start higher. Sized here at 10 GB for 20 concurrent players.
The Bedrock dedicated server is written in C++ rather than Java, so it has no JVM heap to size and runs far leaner at the same player count. This is why the calculator sizes the two editions differently. Sized here at 3 GB for 20 concurrent players.
Roughly +0.1 GB per concurrent player on vanilla and plugin servers, +0.2 GB on modded ones where each player loads a heavier set of chunks, then rounded up to the nearest plan we sell. Sizing is by concurrent players, never by whitelist length.
When More RAM Will Not Help
Past a point, adding memory stops helping and starts hurting. Two hard reasons why.
The garbage-collector tradeoff
A larger heap takes the collector longer to sweep, and on Java that sweep pauses the server. A 32 GB heap on a world that needs 8 GB trades short frequent pauses for long infrequent ones, which players feel as periodic freezes rather than smooth play.
8 GB heap, right-sized
short, frequent, unnoticed
32 GB heap, oversized
rare, long, felt as a freeze
The 32 GB pointer cliff
Below 32 GB the JVM compresses object pointers to save space. Cross that line and pointers grow, so a 33 GB heap can hold less useful data than a 31 GB one. Worth crossing only when the world genuinely needs it, not as a precaution.
Bar length is useful data held, not heap size. More memory, less room.
These are tick-rate symptoms, not memory ones
If you recognise any of these, work through the fix before you buy another tier. Check which mod is eating the tick first.
Chunks load slowly as players move
Lower simulation distance and pregenerate out to the world border.
Mobs freeze in place mid-air
Clear out oversized mob farms and cap entities per chunk.
Blocks reappear after you break them
The server is behind on ticks. Profile the tick before adding memory.
Periodic freezes on an already large heap
Shrink the heap instead of growing it, then re-measure.
Redstone and hoppers run visibly late
Split hopper chains and clocks, or move them out of loaded chunks.
Lag spikes only when players teleport or fly
Cap chunk generation per tick and pregenerate the destination area.
Frequently Asked Questions
Have questions? Find answers to the most common queries about plans, setup, and managing your game server to help you launch quickly and enjoy smooth multiplayer gameplay.
