Skip to content

Minecraft

How much RAM does a Minecraft server need?

How much memory a Minecraft server needs for a group of friends, a public server with plugins or a modpack — and why RAM alone won't fix lag.

5 min readBlazeHost


"How much RAM do I need?" is the most common question before ordering a Minecraft server. The honest answer: it depends on what will run on it. A world for a few friends on Paper has different needs from a public server with an economy, and a modpack with a hundred or more mods is another story altogether. This article gives rough figures together with the assumptions behind them, explains what actually uses memory on a server, and — most importantly — why RAM alone often won't fix lag.

The quick answer

The figures below are a starting point, not a guarantee. They assume one world, a normal render distance (view distance 8–10) and no other processes running alongside the server, such as a separate database or a web map.

ScenarioRough guideAssumptions
A group of friends4 GBPaper or Vanilla, a few common plugins, vanilla world generation, up to roughly 10 concurrent players.
Public server with plugins8 GBPaper, economy and land protection plugins, scheduled restarts, up to roughly 30 concurrent players.
Light modpack6–8 GBFabric, Forge or NeoForge with a few dozen mods, a smaller community.
Large modpack12 GB and upRoughly 150 mods, custom world generation, a small closed community.

On the newest Minecraft versions, lean towards the upper end — newer versions keep more world data in memory than older ones. The reserve you need also grows with player count: above roughly 40 concurrent players it is worth going one tier higher. For an estimate tailored to your configuration, use the advisor on the Minecraft plans page — the result always shows what it is based on.

What uses memory on the server

A Minecraft server is a Java program, and most of its memory lives in the so-called heap, whose maximum is set by the -Xmx parameter. The heap mainly holds:

  • Loaded chunks. An area around each player stays loaded according to the view distance. Players spread across the world mean more loaded chunks than players standing in one place.
  • Entities and block data. Animals, mobs, dropped items, chests, hoppers, redstone. Large farms can load memory and CPU more than a dozen players.
  • Plugins and mods. Each keeps its own data. Mods also add new blocks, items and world generation, which is why modpacks start from a much higher baseline.
  • Headroom for the garbage collector. Java frees unused objects continuously and needs free heap space to do it.

On top of that, the Java process needs memory outside the heap (for loaded classes, threads and native libraries, for example). That is why the heap is never set to the machine's or container's entire memory. If the process outgrew its allocated limit, the system would kill it. On hosting, the panel handles this: it sets Java memory according to your plan, and you should not raise it by hand above what is allocated.

The server software matters a lot as well. Neither Vanilla nor Paper adds much overhead on its own, and Paper is also optimised for performance, which is why we treat it as the baseline for plugin servers. The Fabric, Forge and NeoForge mod loaders are a different case: every mod adds its own content, so a modpack needs noticeably more memory right at startup, before the first player even joins. If you are deciding between plugins and mods, factor this in when choosing the server size.

Why more RAM often won't fix lag

The Minecraft world is computed in ticks — ideally 20 per second, so the server has 50 ms per tick. This is what the TPS (ticks per second) and MSPT (milliseconds per tick) metrics measure. A large part of the work in each tick runs on a single main thread. When a tick takes longer than 50 ms, TPS drops and players see lag. So what matters most is single-core CPU performance and how much work the server does per tick — not the amount of memory.

The most common causes of lag that more RAM won't help with:

  • Generating new chunks. When players explore new terrain, the server has to create the world first. Setting a world border and pre-generating the world helps, for example with the Chunky plugin.
  • Simulation distance set too high. Every chunk within simulation range is processed every tick. The view-distance and simulation-distance settings are described on the Minecraft Wiki.
  • Entities and farms. Hundreds of animals in one pen or overloaded hoppers strain the main thread regardless of memory.
  • A specific plugin or mod. One badly written add-on can slow down the whole server.

The most reliable way to find the cause is the spark profiler. Our guide Minecraft server performance walks through it step by step.

Can there be too much memory?

Memory the server doesn't use won't make it faster. A heap set needlessly high only postpones garbage collection — the collector then deals with more data at once, and individual pauses can get longer. And if the heap reaches the machine's or container's limit, there is no room left for off-heap memory and the process can crash. It is more sensible to size memory to actual usage plus a reasonable reserve.

If you launch the server yourself, the Paper documentation recommends the so-called Aikar's flags — a set of G1 garbage collector settings tuned for Minecraft. Among other things, they recommend setting -Xms and -Xmx to the same value and not giving Java all of the machine's memory.

How to tell memory is really running out

  • Memory usage in the panel graphs stays at the limit for long periods and doesn't drop after collection.
  • The spark health command or a spark report shows frequent, long garbage collection pauses.
  • The server crashes with an OutOfMemoryError.
  • The problem gets worse with each plugin or mod you add, even though the player count stays the same.

If none of this applies and the server still lags, look for the cause in the CPU, world generation or a specific add-on. For modpacks, the memory recommended in the modpack description is best treated as a minimum — more in our guide to installing modpacks. Add-ons on Paper are covered in installing plugins.

💡 Tip:Before adding a large modpack or changing versions, create a backup in the panel. The automatic nightly backup (we keep the last 5 days) is only a safety net — before a change it pays to have a fresh manual one. See the guide to backups and version changes.

How it works with us

BlazeHost Minecraft servers run on our own hardware with AMD Ryzen 9 5900X processors and NVMe SSDs, colocated in the firstcolo FRA4 datacentre in Frankfurt am Main. RAM and disk are dedicated to your plan, plans start at 2 GB from 60 CZK per month, and you can add memory in the client area — it applies after a restart, and your world and configuration stay in place. The server is set up automatically after payment and you manage it in the Pterodactyl panel. If you are unsure about sizing, get in touch and we will go through your configuration.

Summary

  • Paper with a few plugins for roughly 10 players: 4 GB. A public server with plugins for roughly 30 players: 8 GB. A large modpack of around 150 mods: 12 GB and up.
  • Newer Minecraft versions, more players and a higher view distance all push memory needs up.
  • Lag is usually caused by single-thread performance, chunk generation, entities or a specific plugin — not a lack of RAM.
  • Pre-generate the world, keep simulation distance sensible and measure with spark.
  • Add memory only when the data shows it is genuinely running out. Surplus RAM won't add performance.

Minecraft servers on our own hardware in Frankfurt

Paper, Fabric, Forge and modpacks in the Pterodactyl panel, DDoS protection included.