By The Quantum Host Team — engineers who operate the platform.
Almost every RAM recommendation you'll find is a table with no reasoning behind it. That's a problem, because the honest answer depends on four things — player count, view distance, world size and mod count — and they don't contribute equally. View distance in particular costs far more than most people expect.
This walks through where the memory actually goes, so you can size a server for your own case instead of guessing from someone else's table.
Where the memory actually goes
A Minecraft server's heap is dominated by loaded chunks, not by players. Each player loads a square of chunks around themselves determined by view-distance, and the server keeps every one of those chunks — plus its entities, block entities and lighting data — in memory.
That's why view distance is the single biggest lever you control. The loaded area grows with the square of the radius, so going from view-distance 10 to 20 doesn't double the chunk memory, it roughly quadruples it.
- Loaded chunks — the largest share, and it scales with view-distance²
- Entities and block entities — mob farms and hopper chains are the usual culprits
- Mods and plugins — varies wildly; large modpacks can dwarf everything else
- The JVM itself — a few hundred MB before your world is even loaded
Vanilla and lightly-plugged servers
For vanilla or a handful of plugins, players are cheaper than people assume — because they share chunks. Ten friends exploring together in one area load barely more than one player does. Ten players scattered across a world load ten separate chunk squares.
So the number that matters isn't really player count, it's how spread out they are. Size for the spread-out case if you run a survival server with no world border.
- 1–5 players, view-distance 8–10: 2 GB is genuinely comfortable
- 5–20 players, view-distance 8–10: 4 GB, and lower view-distance before adding RAM
- 20–50 players: 6–8 GB, plus a world border to bound total chunk count
- 50+ players: 8 GB+, and at this point you want Paper and pre-generated chunks more than you want more memory
Modpacks change the arithmetic completely
A large modpack can use more memory at idle, with nobody connected, than a vanilla server uses at capacity. Mods add their own block entities, world-generation structures, and background tick work, and many keep their own caches.
Treat the modpack's own recommendation as a floor rather than a target, and add headroom on top for your players. If the pack authors say 6 GB, they usually mean 6 GB for a single player testing it.
- Small packs (under ~50 mods): 4 GB
- Medium packs (~50–150 mods): 6 GB
- Large packs (150+ mods, or anything with heavy worldgen): 8–10 GB
- Kitchen-sink packs: 10 GB+, and expect worldgen to be the bottleneck, not RAM
Why more RAM often makes things worse
This is the counter-intuitive part. Allocating far more heap than you need makes garbage collection pauses longer, because the collector has more memory to walk. Those pauses show up in-game as lag spikes — the thing you were trying to fix.
A 6 GB server that is correctly tuned will usually outperform a 16 GB server that isn't. If you're seeing periodic freezes rather than consistent slowness, the problem is almost certainly GC or a single expensive chunk, not a shortage of memory.
Diagnose before you upsize: run a profiler and look at tick timings. If tick time is fine but you get stutters, that's GC. If tick time is consistently high, that's entities, redstone or worldgen — and no amount of RAM fixes it.
Cheaper levers to pull first
Before paying for more memory, these usually buy more real performance:
- Drop view-distance from 10 to 7 — often a large win, and most players never notice
- Set simulation-distance lower than view-distance (players see far, less is ticked)
- Pre-generate the world so exploration isn't generating chunks live
- Set a world border, which bounds worst-case chunk count
- Switch to Paper, which fixes a long list of vanilla inefficiencies
Common questions
- Is 2 GB enough for a Minecraft server?
- For vanilla with up to about 5 players and a modest view-distance, yes — comfortably. It is not enough for most modpacks, which often need 4 GB before a single player connects.
- Does more RAM increase Minecraft server FPS?
- No. Client FPS is your own machine's graphics work. Server memory affects tick rate and lag spikes, which feel like stutter but are a separate thing from framerate.
- Why does my server lag even with plenty of RAM free?
- Almost always tick-time, not memory: too many entities, heavy redstone, or live chunk generation from players exploring. Profile the tick loop before buying more RAM — spare memory is evidence the bottleneck is elsewhere.
- Should I allocate all available RAM to the server?
- No. The operating system and the JVM's own overhead need headroom outside the heap, and an oversized heap lengthens garbage-collection pauses. Leave room rather than allocating everything.