Palworld 32-Player Ceiling: RAM Growth Curve, Base-Entity Cost and CPU Math

Palworld’s dedicated server has a reputation for memory creep that most operators discover the hard way around day four of a fresh world. The published minimums — 8 GB RAM, 4 cores — are technically true for a two-player private world. They are useless for a public 32-slot server where each player builds a base with 20 Pals and a breeding farm.

Where the RAM actually goes

Palworld memory has three dominant contributors, and only one of them is player count.

Loaded world cells (~4-7 GB): the server keeps a radius of map cells resident around each active player. 32 players spread across the map can force 12-18 cells to stay loaded. Concentrate your players and this drops; scatter them and it climbs.
Base entities (~0.6-1.1 GB per active base): each base with 15 workers, storage chests and production lines holds a persistent entity graph. This is the number that surprises people. A 32-player server with 32 active bases routinely sits at 18-24 GB RSS even when idle.
Pals in the wild and breeding queues (~2-4 GB): Pal AI is ticked server-side, and breeding pens with large queues are the worst offenders.

The practical planning rule: budget 700 MB RAM per active player base plus 6 GB baseline. That gives you 6 + (32 x 0.7) = ~28 GB for a full 32-slot server, which means 32 GB is the real floor and 48 GB is what you want if the server runs for weeks without restart.

Scheduled restarts are not optional

Palworld does not reclaim base entity memory cleanly when a base is demolished or a player leaves. Measured growth on a busy 32-slot server is roughly 1.5-2.5 GB per 24 hours of uptime. A 48 GB node that starts at 20 GB will be swapping by day 12 if you never restart.

# systemd restart timer, every 12 hours at 05:00 and 17:00 UTC
[Timer]
OnCalendar=*-*-* 05,17:00:00
Persistent=true

# in PalWorldSettings.ini
bIsUseBackupSaveData=True
SaveDataSlot=0
RCONEnabled=True
RCONPort=25575

A 12-hour restart cycle with bIsUseBackupSaveData enabled keeps memory under 26 GB on the reference build and caps the worst-case save loss at the save interval. Announce the restart in-game five minutes out — a hard restart mid-raid is the fastest way to lose a community.

CPU: the honest numbers

Palworld does not scale across many cores nearly as well as Rust or Minecraft. Its tick loop handles base production, Pal AI, and raid logic on a small number of threads. In practice:

1-8 players: 4 cores is genuinely sufficient, and pure clock speed dominates. A 5.0 GHz 4-core will outperform a 2.8 GHz 16-core for small servers.
16 players: 6-8 physical cores, 3.8 GHz+ effective. You will see the main thread approach 70% utilisation during base raids.
32 players: 8-12 physical cores at 4.2 GHz+. Beyond 12 cores you gain little on the game loop and are really buying headroom for the save thread and RCON.

Watch single-thread utilisation rather than total CPU percentage. A server reporting 35% total CPU while one core is pinned at 100% is the classic Palworld bottleneck signature, and adding cores will not help.

Storage and save behaviour

Palworld saves the entire world in a small number of Level.sav files. A 32-player world with heavy building reaches 60-140 MB per save — much smaller than Rust, but written far more often under default settings. Palworld’s autosave defaults to every 30 seconds, which on a SATA SSD creates a continuous low-level write stream that competes with the game loop’s own reads.

Set AutoSaveSpan to 120-180 seconds. NVMe is strongly preferred here not for throughput but for latency: the save write must complete before the tick loop resumes cleanly. Our dedicated server comparison table flags which plans ship NVMe in a RAID1 pair, which matters because a lost Level.sav on Palworld is rarely recoverable from a partial backup.

Mods change the ceiling

Server-side mod loaders are still maturing in 2026, but the ones in wide use (UE4SS-based stacks) add 20-40% to baseline RAM and introduce per-tick Lua overhead. If you plan to run mods, size up one RAM tier and assume a 200-300 player-base equivalent cost on the CPU main thread. If you are weighing whether to run modded and vanilla worlds on the same chassis, compare bare-metal specs side by side first — the two workloads have opposite scaling profiles (mods want RAM and single-core clock, vanilla wants core count) and often justify separate nodes.

World settings that reduce hardware pressure

Three PalWorldSettings.ini values directly reduce entity count and therefore RAM and tick cost, without gutting the game:

BaseCampMaxNumInGuild — cap at 3 rather than the default 4 for 32-slot servers. One fewer maxed base per guild on a full server removes roughly 20-30 active base entity graphs.
PalSpawnNumRate — set to 0.8 instead of 1.0. Wild Pal AI is ticked server-side and a 20% reduction is barely perceptible in play but noticeably cheaper per frame.
DropItemMaxNum — default is 3000 and dropped loot is a persistent, non-expiring entity type on many servers. Halving it removes thousands of lingering item entities from the world save and its memory footprint.

Combined, these three changes typically pull 3-5 GB off the RSS of a mature 32-slot server — which is the difference between 48 GB being comfortable headroom and being the hard wall you hit on day ten.