Sizing a Palworld server: RAM and CPU

Palworld has a reputation for being heavy, and it is deserved. But the load does not come from where people assume: it is not the player count that costs most, it is Pals and bases.

What actually consumes

Pals assigned to bases

Every working Pal is a permanently simulated entity: it moves, produces, eats, gets tired. A base with twenty Pals costs more than one extra connected player.

Number of bases

Each base is a simulation point that stays active. A community where everyone built their own base somewhere different costs far more than a group sharing two settlements.

Wild Pals

The spawn rate you set in the config is paid for here. Raising world density makes the map feel alive and makes the server noticeably heavier.

Players, last

They count, but mostly through what they create: their bases and their Pals. Ten players sharing one base cost less than three players with two bases each.

Clock speed over core count

Palworld does not scale well across many cores. A high-frequency CPU makes a noticeably smoother server than a many-core, slower one at comparable price. This is a point where the machine choice matters more than the plan choice.

Signs you are short

• Regular, spaced-out stutters during autosaves.
• Pals freezing in bases or stopping production.
• A server restarting on its own with no explicit error in the logs.

The second symptom is the most Palworld-specific: when the simulation falls behind, working Pals are the first thing to drop out.

Sizing without overpaying

Start from the number of planned bases and Pals per base, not from the number of friends. A simple rule: a community playing around two or three shared settlements fits on a far more modest plan than a scattered community of the same size.

Our Palworld hosting plans change while keeping the world, so starting small and scaling as bases multiply is the cheapest strategy.