The first question almost everyone asks when they spin up a world is how much RAM for a Minecraft server they should pay for. The honest answer is usually less than the forums scared you into buying, unless you're running modpacks. RAM matters. But it's one piece of the puzzle, and pouring more of it onto a laggy server almost never helps. Here are the straight numbers, then what actually moves the needle.
The short answer, by player count
This is a practical mapping for a vanilla or lightly-plugged server, assuming normal survival play, a sane view distance, and a world that isn't wildly bloated. Starting points, not gospel.
- 1 to 5 players, vanilla or Paper: 2 GB is plenty. You can limp along on 1 GB, but Java's garbage collector gets cranky under 2.
- 5 to 10 players: 3 to 4 GB. The sweet spot for most friend groups.
- 10 to 20 players with a handful of plugins: 4 to 6 GB.
- 20 to 40 players, plugin-heavy (a proper community server): 6 to 8 GB.
- Small modpack (up to ~100 mods), 2 to 5 players: 6 to 8 GB. Mods are hungry.
- Large modpack (200+ mods) like All The Mods or a big FTB pack: 8 to 12 GB, sometimes more. GregTech-style packs will happily eat 16.
Look at that fifth line against the fourth. A five-person modpack wants more RAM than a forty-person plugin server. That's the whole story compressed into one sentence: the software you run matters far more than how many people are online.
Vanilla vs plugins vs modpacks
Vanilla and Paper are frugal. A stock Paper server on 4 GB will host a dozen people without breaking a sweat. Honestly, just use Paper. It's a drop-in vanilla replacement that runs the exact same worlds, tracks the latest Minecraft version closely, and its async chunk handling alone buys you more real performance than doubling your memory ever would. If you're still deciding on a server flavor, our Minecraft Paper hosting page lays out why it's the default we hand almost everyone.
Plugin servers (Paper, Purpur, Spigot) add a little memory cost per plugin, but most plugins are featherweight. The ones that aren't are predictable: a dynamic map renderer like Dynmap or BlueMap, a land-claim plugin holding tens of thousands of regions, an economy plugin keeping a big database resident. Budget an extra gig or two over your vanilla baseline and you've covered it.
Modpacks play by different rules. Forge and Fabric load every mod's classes and assets into memory at startup, and worldgen mods carve out far more complex chunks. This is the one place where RAM genuinely becomes your ceiling. Check the pack's recommended allocation on its CurseForge page, then add headroom on top. When a pack says "6 GB minimum," it really wants 8 in practice, because "minimum" means "the point below which it crashes," not "the point where it runs well."
How much RAM for a Minecraft server won't fix lag
This is the part I wish more tutorials opened with. Minecraft's tick loop runs on a single main thread. Twenty ticks a second is the target, so the server has 50 milliseconds to finish all its work each tick. Blow past that and you lag, no matter how much memory is sitting idle. Watch it with the /tps command, or on Paper with /spark tps. If your milliseconds-per-tick (MSPT) creeps over 50, you have a CPU or logic problem, and no amount of extra RAM touches it.
Think of RAM as a bucket. It has to be big enough to hold everything at once, but a bigger bucket doesn't make the water pour faster. Over-allocating actively backfires: hand Java 20 GB when it needs 6 and garbage-collection pauses get longer, because the collector has more heap to sweep every cycle. Those pauses land as periodic stutters your players will swear is "lag." On anything up to about 12 GB I'd point the G1 collector at a sane target with Aikar's flags (they bundle -XX:MaxGCPauseMillis=200 and a stack of others) instead of hand-tuning. They're battle-tested and they exist for exactly this problem.
So what does cause lag? Almost always one of a short list: a mob farm or hopper array ticking thousands of entities, chunk generation as players explore fresh terrain, an oversized redstone contraption, or one badly-behaved plugin. When your server stutters, profile it before you buy memory. We wrote a full walkthrough on how to fix Minecraft server lag that covers reading a spark report and cornering the usual suspects.
View distance and simulation distance
Two settings in server.properties quietly drive your CPU and memory harder than almost anything else. view-distance sets how many chunks each player can see; simulation-distance sets how far the world actively ticks (mobs, crops, redstone). The math is unforgiving. A player at view distance 10 loads a 21-by-21 block of chunks, and every extra ring of radius is bigger than the last.
The default is 10. On a public server with more than a few people, drop view-distance to 8 and simulation-distance to 6, or even 5. Players almost never clock the visual difference, and your tick times and heap both fall off noticeably. Cranking view distance to 32 "for the views" is one of the quickest ways to cook a server. And keep that simulation number low specifically: it's the one that burns CPU, not just memory.
Chunk loading and pre-generating with Chunky
A big chunk of "random lag spikes" is just fresh terrain being born. Sprint into unexplored land and the server has to build those chunks on the fly, which is expensive, brutally so in modded. Each new chunk then sits in memory until it unloads, so heavy exploration quietly inflates your heap on top of the CPU hit.
The fix is to pre-generate the world inside your border before anyone plays on it. Chunky is the plugin (and Fabric mod) everybody reaches for. Set a world border, run /chunky radius 5000 then /chunky start, and let it grind through terrain while the server's empty. Once it finishes, players wandering around are just pulling pre-built chunks off disk instead of generating them live. For a fresh survival server it's the single highest-value thing you can do, and it costs nothing but some patience and disk space. Run it before your grand opening, not during it.
Picking a number and moving on
Want one figure to start with? 4 GB covers the overwhelming majority of vanilla and Paper servers up to fifteen or twenty players. Modpacks start at 8. Bump the memory only when a spark report proves you're actually running short (frequent full GCs, heap pinned near the ceiling), not because a number looked small to you. Once your RAM is adequate, CPU single-thread speed and fast NVMe storage carry just as much weight for how smooth things feel.
Building your first server from scratch? Our guide on how to make a Minecraft server walks it end to end. And if you'd rather not tie up your home PC and connection (or wear the DDoS-mitigation headache yourself), our game server hosting lets you pick a plan, run Chunky, and be online in a couple of minutes across Frankfurt, London, or Gravelines. So don't overthink how much RAM for a Minecraft server you need on day one: start modest, keep an eye on your TPS, and add memory only when the server tells you it's time.