Datapacks vs mods on a Minecraft server: what each one can actually do

Key takeaways

• A datapack changes the game using systems the vanilla server already has; a mod changes the game by adding code to it. That one difference decides almost everything else.
• Datapacks need no loader, no client install and no version-locked dependency chain, which makes them far cheaper to maintain on a server with real players.
• Mods can do things datapacks structurally cannot – new blocks with new behaviour, rendering changes, new UI – so the real question is whether what you want needs that.

Every server owner eventually hits the same decision. You want the world to have more in it than vanilla provides. There are two ways to get there and the difference is not obvious from the outside, because the end result can look identical.

Towns and Towers is a good example of why this matters right now. It has been a structure mod for years, requiring Fabric or NeoForge on the server and often on the client. It now also ships as a datapack build that drops into a vanilla server with no loader at all – our coverage of that release goes into what changed. Same structures, completely different operational cost.

What a datapack actually is

A folder of JSON and function files that the vanilla server reads at load. It can define:

• New crafting, smelting and smithing recipes
• New loot tables – what mobs drop, what chests contain
• New structures and how they generate
• New biomes, new worldgen rules, new dimensions
• New advancements, which double as event triggers
• Functions – lists of commands the server can run on a schedule or on a trigger
• New predicates, item modifiers and damage types

That is a long list, and people routinely underestimate it. A datapack can add a dimension. A datapack can make a mob drop something it has never dropped. A datapack can run logic every tick.

What it cannot do is add behaviour the game engine does not already have. There is no way to write a block that does something no existing block does, because you are configuring systems rather than writing code.

What a mod can do that a datapack cannot

The honest list is shorter than people expect, but the items on it are significant:

• New block and item behaviour. A machine that processes items over time, a tool with a new mechanic, a block with a custom inventory. Datapacks can fake some of this with armour stands and commands, and it is always worse.
• Rendering changes. Anything about how the game draws. Our 3D model pack notes cover what resource packs reach, and beyond that you need code.
• New UI. Custom screens, menus, HUD elements.
• New entities with new AI. You can reskin and reconfigure existing mobs; you cannot write new pathfinding.
• Performance work. Every meaningful optimisation mod rewrites engine internals. Our server performance stack covers the ones worth running.
• Networking and protocol work. Crossplay through a proxy, for instance – see our Geyser guide.

The operational difference is the real argument

This is the part that gets skipped in comparisons, and on a server with players it matters more than the capability list.

Version upgrades. A datapack usually needs a pack format bump and nothing else. A mod needs the author to update, then every dependency to update, then the loader. On a modded server, one unmaintained mod holds the entire server on an old version. Our version migration guide covers the process and the mod case is where it gets painful.

Client requirements. Server-side datapacks need nothing from players. They join with a vanilla client. Many mods – anything with new blocks, items or rendering – need every player to install the same mod at the same version. For a public server that is a wall; for a friends server it is a weekly support request.

Failure modes. A broken datapack logs an error and the affected feature does not load. A broken mod can crash the server on startup or corrupt chunks.

Install and removal. A datapack is a folder in the world directory and /datapack disable turns it off live. Removing a mod that added blocks leaves those blocks as holes in the world. Our worldgen mod guide covers the related problem of adding one mid-world.

None of this means mods are a bad choice. It means a mod has to be worth the cost, and a surprising number of features people reach for mods to get do not need one.

Where plugins fit

Worth clearing up, because the three terms get used interchangeably and they are not the same.

Plugins are the Bukkit/Spigot/Paper family. They run server-side only, require no client install, and can do far more than datapacks because they are real code with access to server internals. They cannot add new blocks or items properly, because the client does not know about them.

So the actual spectrum runs: datapack (no code, no client install, vanilla server) to plugin (code, no client install, Paper-family server) to mod (code, usually client install, Fabric/NeoForge server). Our plugins vs mods guide covers the middle of that, and our server software comparison covers which server software supports which.

One note that catches people: a Paper server runs datapacks fine. Datapacks and plugins are not alternatives – most well-run servers use both.

How to decide

A short sequence that resolves most cases:

1. Write down the feature, not the solution. “I want villages to be more interesting” rather than “I want Towns and Towers”.
2. Ask whether it is configuration or behaviour. New recipes, loot, structures, biomes, dimensions, scheduled events – configuration, so a datapack can do it. New mechanics, new UI, new rendering – behaviour, so you need code.
3. If it is behaviour, ask whether players need to see new content. No means a plugin. Yes means a mod.
4. Check whether a datapack version already exists. This is the step people skip. Several well-known structure and worldgen mods now ship datapack builds.
5. Count the client installs. If a mod means every player installs something, that is a real cost – price it before committing.

Running both

Most servers end up mixed, which is fine, but a few things are worth getting right.

Load order matters for conflicts. Two datapacks that modify the same loot table do not merge – the one loaded later wins. /datapack list shows the order and you can change it.

Back up before enabling anything. Especially worldgen, where a bad datapack can generate chunks you cannot undo. Our backup routine guide covers doing this properly rather than copying the folder occasionally.

Test on a copy. A second world with the same packs, generated fresh, tells you within minutes whether anything conflicts.

Keep a written list of what is installed and why. A year later, the pack you cannot remember adding is the one blocking your upgrade.

The direction this is going

Worth noting for planning purposes: the datapack side of the line keeps moving. Every version adds data-driven systems that previously needed code – worldgen moved first, then damage types, then enchantments. Features that required a mod three years ago are datapack territory now.

That does not threaten mods. It means the list of things that genuinely need one keeps getting more specific, and the cheap end keeps getting more capable. For a server owner choosing today, the practical advice is simply to check the datapack option first, because it is more often available than it used to be.

If you are still setting up, our hosting guide covers the specs question, which changes a lot depending on which side of this line you land on – a vanilla server with datapacks runs on far less than a modded one.

Images: Fresh Animations project gallery.