minecraftserver-managementperformancepaper

Paper vs Purpur vs Pufferfish: Choosing a Performance Fork for a Small SMP

A practical walk through what Paper, Purpur, and Pufferfish actually change, which config knobs matter, and how to pick a performance fork for a small SMP.

ChunkPod Team · September 23, 2026 · 9 min read

Paper vs Purpur vs Pufferfish: Choosing a Performance Fork for a Small SMP

A small SMP doesn't need the same server software a 200-slot public network does. But if you've spent an evening watching your TPS dip while three players load new chunks, the choice of server jar starts to matter. Paper, Purpur and Pufferfish are the three forks a lot of small SMP admins end up picking between. All three are drop-in replacements for the vanilla server, and all three claim to be faster. What they actually change, and what they leave alone, is different for each one.

Here's a walk through what each fork does, which config knobs are worth knowing, and how to think about the trade-off between raw TPS and staying close to how vanilla behaves.

What "performance fork" actually means

A fork is a modified version of an existing server jar. Paper is a fork of Spigot, which is itself a fork of the vanilla Minecraft server. Purpur is a fork of Paper. Pufferfish is also a fork of Paper. Every fork inherits the changes of the ones underneath it, so a Purpur server is a Paper server with more knobs and some extra behavior toggles.

"Performance" in this context usually means one of three things:

Reducing the cost of things the server already does, such as mob AI, chunk loading or entity tracking.
Skipping work the server does but doesn't strictly need to do every tick.
Letting the admin turn off features they don't want, so the server stops spending CPU on them.

The three forks lean on those in different amounts.

Paper

Paper is the default answer for anyone who wants more than vanilla. It patches a long list of vanilla bugs, fixes duplication exploits that Mojang hasn't gotten around to, and rewrites parts of the server for speed. Anti-xray is built in. Async chunk loading is baked in. Most of the plugin ecosystem targets Paper directly.

The important thing to know is that Paper does change some vanilla behavior on purpose, and those changes are configurable. The config that matters lives in a few files:

paper-global.yml holds server-wide settings such as anti-xray mode, watchdog timings and proxy handling.
paper-world-defaults.yml holds per-world defaults for entity activation range, mob spawn limits and chunk-related tuning.
Any per-world overrides live in a paper-world.yml next to that world.

The knobs a small SMP admin actually touches:

view-distance and simulation-distance in server.properties. Simulation distance is separate from view distance on modern Minecraft versions. Lowering simulation distance while keeping view distance high lets players see far without simulating far.
entity-activation-range in paper-world-defaults.yml. This is how far a mob has to be from a player before the server stops ticking its AI. Lower values mean less CPU on mob AI, at the cost of mobs freezing when they're further out.
spawn limits in bukkit.yml and per-player-mob-spawns in Paper. Per-player mob spawns are on by default and are one of the reasons Paper feels smoother than Spigot on populated servers.
anti-xray in paper-global.yml. Engine mode 2 is more expensive than mode 1, and both cost some chunk generation time. If nobody's mining with X-ray, you can leave it off.

Paper's mindset is "keep vanilla mostly intact, fix what's broken, expose what needs tuning". If you don't touch a single config file, you get a server that plays almost exactly like vanilla, just with fewer bugs and better throughput.

Purpur

Purpur is a fork of Paper aimed at admins who want to change how the game plays, not just how the server performs. If Paper's mindset is "vanilla but faster", Purpur's is "vanilla but with every switch you didn't know you wanted". A big chunk of what Purpur adds is optional gameplay tweaks:

Ridable mobs. Chickens, pigs, striders, ravagers, all optional and off by default.
Configurable mob behavior, such as whether phantoms attack sleeping players or whether zombies burn in daylight.
Item and block tweaks: how many uses a bucket has, whether beacons need a pyramid, how far a projectile travels before it despawns.
Toggleable vanilla mechanics that some communities want changed, such as villager trade behavior or elytra glide rules.

All of that lives in purpur.yml and the per-world Paper config. The config file is long. Very long. That's the point.

The performance side comes from what Purpur inherits, plus some optimizations pulled in from other forks over time. It also gives you toggles for behaviors that don't cost much on their own but add up: for example, disabling phantom spawning entirely, tightening item cramming rules, or capping how far a projectile can travel before it despawns.

The config knobs that matter most for TPS on Purpur, beyond the Paper ones:

Gameplay mechanic toggles in purpur.yml, especially anything that disables a spawn category or a mechanic your server doesn't use.
Villager settings if your SMP has a lot of iron farms or trading halls. Purpur exposes things like villager lobotomize behavior that let you cap how expensive a single villager is to tick.
Idle timeout and AFK handling, which lets you stop simulating players who have wandered off from the keyboard.

Purpur's trade-off is scope. There is more surface area, more toggles, and a lot of them are gameplay decisions. Turning them on drifts your server further from vanilla. On a small SMP where six friends want a mostly-vanilla feel, most of Purpur's toggles will sit at their defaults, and you'll be running what is essentially Paper with a few extra optional bits.

Pufferfish

Pufferfish is a fork of Paper focused only on the server side. It doesn't add gameplay toggles. It doesn't change how mobs behave from the player's point of view, at least not on purpose. What it does is take specific hot paths in the server and rewrite them to be cheaper.

The headline features:

DAB (Dynamic Activation of Brains). Villager and other mob "brains", the modern replacement for the old mob AI, get ticked less often the further they are from a player. Villagers standing in a trading hall a hundred blocks away don't get the same brain tick rate as a villager standing next to a player. On servers with big iron farms or lots of villagers, this is where a lot of the TPS goes.
Async pathfinding. Mob pathfinding runs off the main server thread. If a horde of zombies decides to pathfind at once, the main thread doesn't stall waiting for them.
Async entity tracker. The bookkeeping for which entities each player can see moves off the main thread.
Small rewrites of hot code paths, such as raid ticking and inventory checks.

The config lives in pufferfish.yml. It's short. The main knobs:

dab.enabled and dab.start-distance. DAB is on by default. Start distance is how close a mob has to be to a player before it gets full brain ticks. Lowering it saves more CPU, at the cost of mobs behaving less responsively at range.
Async toggles, which are on by default and rarely need touching.
Feature flags for the smaller optimizations, most of which you can leave alone unless timings tell you to look at one.

Pufferfish's trade-off is fewer knobs and a narrower feature set. It doesn't add gameplay options at all. What you gain is that vanilla mechanics stay vanilla, and what changes is mostly invisible unless you go looking for it. That makes it a good fit for a small SMP that wants a smoother tick without changing how the game plays.

One thing worth knowing: Pufferfish's development pace has been uneven, and the wider community has spun up follow-on forks such as Leaf and Petal that build on similar ideas. If you're picking a fork today, check that the version you want to run is being actively maintained for the Minecraft version you're on. That advice goes for every fork on this list.

The trade-off, in plain terms

TPS is not a single dial. What you're really trading between these three is:

How close to vanilla you want to stay. Paper drifts a little. Pufferfish drifts a little further in ways players won't notice unless you tune DAB aggressively. Purpur can drift as far as you want, or not at all, depending on which switches you flip.
How much time you want to spend in config files. Paper has enough config to matter. Purpur has enough to fill an evening. Pufferfish has few enough options that you can read the whole file in ten minutes.
How much of your server's load is mob AI. If your friends have built ten villager halls and an iron farm, Pufferfish's DAB will help more than any single Paper knob. If your server's load is chunk loading and player count, Pufferfish helps less, and view and simulation distance in Paper help more.

For a small SMP with three to twelve players, the honest picture is:

Most of the time, plain Paper on sensible defaults is fine. You'll spend more time playing than tuning.
If you have specific gameplay tweaks you want, such as disabling phantoms or making pigs ridable, Purpur exists for that reason.
If you have a real, measurable TPS problem that shows up as mob AI or entity ticking in a timings report, Pufferfish (or a maintained fork like it) is worth trying before you start turning down view distance.

Picking one

Start with Paper. Get a baseline. Learn where the config files live and what the important knobs do. If you find something Paper won't let you tune, that's your reason to switch. If your community wants gameplay changes, look at Purpur. If your community wants the same game to run smoother, look at Pufferfish.

The one thing you don't want to do is switch forks trying to fix a problem you haven't measured. Turn on Paper's built-in timings, look at what's actually eating the tick, and pick the fork that changes that specific thing. All three of these forks are fine software. None of them will save a server that's under-provisioned or full of laggy plugins.

If you'd rather not run the server yourself, ChunkPod is in early access, and you can join the waitlist at chunkpod.com. There's also a JVM Arguments Generator at chunkpod.com/tools that handles the startup-flags side of things whichever fork you end up on.