Palworld server RAM: how much do you need?
Measured against its player cap, Palworld asks for more memory per player than anything else here — and the figure you need at launch will not be the figure you need a few weeks in.
Recommendation
You need a server with at least
12GB
- Engine / Base OS:
- 8 GB
- Player Overhead:
- +2.0 GB
- Estimated Raw Usage:
- 10 GB
- Suggested cores:
- 4
- Disk to allow:
- 15 GB+
Unreal Engine 5 spreads across cores, but base and Pal AI still concentrate on a few.
View 12GB PlansAdvertisement
What uses the memory in Palworld
Under the hood is Unreal Engine 5, holding every base, every building and the AI state of every captured Pal in memory at once. Usage creeps upwards over a session, since the server is known for hanging on to memory it ought to free, so a world that started at 8 GB can be well past it by the weekend.
Palworld server RAM by player count
The calculator above, run for 3 common sizes. Each figure is rounded up to a plan size people actually sell.
| Players | Standard Rates | High Spawn Rates / Late Game |
|---|---|---|
| 8 | 12 GB | 16 GB |
| 16 | 12 GB | 24 GB |
| 32 | 16 GB | 24 GB |
Advertisement
Where people get it wrong
Planning around a brand-new world. The same 32-slot server will need several gigabytes more once it is running a mature save with a handful of big bases. Build that margin in from the start, and restart the server nightly to claw back what the process keeps.
Settings that change the bill
A few lines in PalWorldSettings.ini move memory and CPU more than player count does. PalSpawnNumRate sets how many wild Pals exist, and raising it is the quickest way to make a server heavy. BaseCampWorkerMaxNum sets how many Pals can work at each base, up to 50, and the developers note that raising it raises processing load: every working Pal is simulated whether or not anyone is nearby. bIsUseBackupSaveData turns on world backups, which costs disk activity rather than memory.
The old performance flags
Many guides still tell you to start the server with -useperfthreads -NoAsyncLoadingThread -UseMultithreadForDS. Those were the standard advice for early versions. Pocketpair's own documentation now says that from v1.0 on, leaving them unset may perform better, so on a current build start without them and add them back only if you measure an improvement.