RAM is the first thing people think about when a Minecraft server lags. Often that is correct, but not always. Too little memory causes stutters, long pauses, and startup crashes on large modpacks. But if you add RAM to a server that is really overloaded on tick time or running with view distance too high, the problem will not disappear.
This guide helps you choose a sensible starting plan and understand when memory is actually the bottleneck.
Quick recommendation
For small groups, start here:
- Vanilla or Bedrock, 2 to 5 players: 2 to 4 GB RAM.
- Paper survival with a few plugins: 4 GB, or 6 GB for a larger world.
- Paper with several plugins, a map plugin, or higher view distance: 6 to 8 GB.
- Light Fabric or Forge server: 6 to 8 GB.
- Medium modpack: 8 to 10 GB.
- Large kitchen-sink modpack: 10 to 16 GB.
- Large modpack with more players and chunk loaders: 16 GB or more depending on the world.
These numbers are starting points, not laws. A Minecraft world changes over time: day one may run perfectly, while week three has farms, entities, loaded chunks, and several bases.
What RAM actually holds
A Minecraft server uses memory for:
- loaded chunks and world data,
- entities, items, mobs, and villagers,
- plugins or mods,
- Java caches and internal data structures,
- new terrain generation,
- dimensions and structures in modpacks.
Player count matters, but it is not the only or biggest factor. Two players flying with elytra and generating new chunks can stress a server more than six players standing in one base.
Signs that RAM is the problem
Typical low-memory symptoms:
- the server freezes in short, repeated pauses,
- logs show frequent garbage collection pauses,
- a modpack crashes during startup or world loading,
- teleporting or dimension travel causes long stalls,
- performance gets worse after a few hours until the server restarts.
With Java, low memory does not always mean an immediate crash. More often, garbage collection runs aggressively and pauses the server for fractions of a second. Players experience this as rubber-banding, delayed block breaking, or general stutter.
When RAM is not the main issue
Not every lag problem is fixed by a bigger plan. If the server logs "Can't keep up" while memory still has headroom, the problem may be tick time, not RAM.
Common causes:
- view-distance or simulation-distance set too high,
- fast exploration and new world generation,
- too many entities in one area,
- mob farms, loose items, and villagers,
- large redstone or technical machines,
- a plugin or mod doing expensive work every few ticks.
In those cases, lower view distance, limit chunk loaders, and inspect entities before upgrading.
Vanilla, Paper, and Bedrock
Vanilla is simple, but for Java servers, Paper is often the better default for a friend group. It has stronger performance options, supports plugins, and gives you more settings without requiring every player to install mods.
Bedrock servers have a different ecosystem and can be lighter for simple play, but large worlds, more players, and high render distances still increase load.
For a normal friends-only survival world, it is better to start with a sensible plan and observe the server than to buy the largest option immediately.
Why modpacks need more RAM
Modpacks load a lot of code and data before the first player connects. A large pack can include hundreds of mods, custom recipes, quests, structures, dimensions, and world generation. That is why even a small group needs more RAM on a modpack than the same group on vanilla.
The biggest factors are:
- number of mods,
- custom worldgen,
- extra dimensions,
- tech automation,
- chunk loaders,
- many entities and item transport systems.
If a modpack crashes on startup, the issue may be the wrong server pack or a missing dependency, not just RAM. We cover that in how to host a modpack server.
Why more RAM is not always better
Giving a server far more memory than it uses is not automatically helpful. Java may run garbage collection less often, but when it does run, the pause can be longer. The goal is healthy headroom, not the biggest number.
A practical rule: the server should not live on the edge, but it does not need double its real usage either. If it uses around 5 GB, a 6 to 8 GB plan is more sensible than jumping straight to 16 GB.
VoxelRun sets the JVM heap based on the plan while leaving memory for the system and container. You do not need to tune -Xmx flags manually, which is one of the easiest ways to create a worse problem.
A practical sizing process
- Identify the server type: vanilla, Paper, Bedrock, or modpack.
- Count the real simultaneous players, not everyone in the Discord.
- Consider view distance, plugins, mods, and expected farms.
- Choose the smallest plan with reasonable headroom.
- After the first sessions, watch logs and behavior. If chunks, mods, or players increase, upgrade.
With pay-as-you-go pricing, choosing a slightly larger plan can be worth it if it keeps the game smooth. You still pay only while the server is running, not for a whole month of unused capacity.
Short version
A small vanilla or Paper server is usually fine with 4 GB RAM. Plugins and light mods push the sensible starting point to 6 to 8 GB. Large modpacks often start around 10 GB and can need 16 GB or more once the world gets busy.
The best decision does not come from a table alone. Watch the server: if memory is full, add RAM; if tick time is overloaded, tune view distance, entities, and automation first.