How many plugins or mods is too many?

The count matters far less than what each one does, because what actually slows a server down is work on the main thread every tick: here is how to audit a plugin list and measure what one plugin really costs you.

6 min read · Updated Oct 21, 2026 · By GuavaHost Team

There is no number

People want to hear "stay under twenty", but it is not a useful answer. A server running forty small, well-written plugins can sit at a flat 20 TPS, while a server running five can be unplayable because one of them scans the world on a timer.

So throw the count away and replace it with a better question: how much work is being done on the main thread, and how often?

What actually costs you

Five things, roughly in order of how much damage they do.

1. Work on the main thread, every tick. The main thread is the single thread that runs your world: mobs, blocks, redstone, player actions. A plugin doing something every tick is spending from a budget of fifty milliseconds, twenty times a second. What a server tick actually is explains why that one thread is the whole game.

2. Listeners on hot events. Some events fire constantly: player movement many times a second per player, block physics on every sand fall and water flow. A plugin that listens to a hot event and does something cheap is fine. One that listens and then checks a region list, or queries a database, gets worse with every player who joins.

3. Database calls in the wrong place. A plugin asking MySQL a question from the main thread stops the world until the answer arrives. Usually that is a millisecond and nobody notices; on a slow query it is a visible freeze. Well-written plugins do that work off-thread and cache the result.

4. Duplicated features. Two plugins doing the same job is the most common waste on a real server: two permission plugins, two chat formatters, two anti-grief systems. Both do the work, both listen to the same events, and sometimes they fight and produce bugs on top of the cost.

5. Memory. Plugins holding large data in memory, such as a full log of every block change, take RAM away from your world. That is not a tick cost directly, but running short on memory produces lag of its own.

Notice what is not on that list: start-up time, jar size, number of config files. A plugin that takes ten seconds to load and then sits idle costs nothing while players are online.

The plugins that usually show up

Not because they are badly made, but because of what they do:

• World and map renderers. A live map like Dynmap renders tiles from your world, which is real work. Manageable, but not free, and the first full render is heavy.
• Logging and rollback plugins. CoreProtect records every block change so you can undo griefing. Worth every tick it costs, and still one of your bigger entries.
• Anything that scans on a timer. Auto-clearing, region checks, land claim recalculation.
• Anti-cheat. Movement checks run on the hottest event there is.
• Big all-in-one plugins installed for one feature and left fully enabled.

None of these are bad plugins to avoid. They are the ones to look at first when your list is long and your TPS is short.

Auditing a plugin list

A thirty minute job, worth doing twice a year.

1. Write the list down. Run plugins in the Console tab, or read the plugins folder on the Files tab. On a modded server, read mods instead.
2. Group them by what they do. Permissions, chat, protection, economy, admin tools, world management, fun. Any group with more than one entry is a suspect.
3. Mark anything you cannot explain. If you cannot say what a plugin does and who uses it, it is a candidate for removal. Plugins installed for a feature you never shipped are very common.
4. Check versions. A plugin built for an older Minecraft version may still load and then misbehave quietly. Anything not updated in a long time deserves a look at its project page.
5. Check dependencies. Some plugins are only there because another one needs them. Removing the dependant leaves dead weight; removing a dependency breaks things loudly.
6. Read the configs of the big ones. Features you are not using are often on by default: a hologram system, a particle effect, a web server.

Then cut: the duplicates first, the unexplained ones second, the unused features third.

Measuring what one plugin costs

The profiler is almost always enough. Run spark while the server is under real load, with players online.

1. Type spark profiler start --timeout 600 in the Console.
2. Open the link it prints when it finishes.
3. Switch to the Sources view, which groups time by plugin or mod and answers "which plugin is expensive" directly.

That one view usually ends the investigation. Find what's causing lag with spark covers the rest of the report, including profiling spikes rather than constant lag. On modern Paper the old timings command has been removed in favour of spark, so if another guide tells you to run timings and it does not exist, that is why.

Sometimes Sources spreads a plugin's cost across event handlers and it is hard to attribute. Then measure it directly with a removal test:

1. Take a snapshot on the Backups page first. Removing a plugin can mean losing its data.
2. Measure a baseline: mspt plus a short profile, with a known number of players online.
3. Remove or disable one plugin, then restart. A reload leaves half of it in memory and makes the result meaningless.
4. Measure again under conditions as close to the baseline as you can get.
5. Put it back or leave it out, then move on to the next one.

What makes this work is one change at a time. Pull three plugins at once and you have learned nothing about any of them.

Mods are the same, with two extras

Everything above applies to Fabric, Forge and NeoForge. Two differences matter. Client-side mods cost the server nothing, so a pack of two hundred mods may only have thirty doing server-side work: judge that list, not the pack size. And mod configs are where the tuning lives, since machines, world generation features and custom mobs usually have caps and intervals in their own files.

Big modpacks also need more memory than plugin servers, so check your Usage card before blaming a mod for what is really memory pressure.

When the plugins are not the problem

Before you spend a weekend auditing, make sure you are chasing the right thing. If your profile points at entity ticking, see cutting entity and mob lag. If it points at chunk generation, pre-generating your world is the fix. And if your view and simulation distances are high, lowering them beats any plugin change you could make.

Common questions

Is forty plugins too many for a Minecraft server?

Not on its own. Forty small plugins that only react to player commands cost almost nothing, while four that scan the world on a timer can ruin your TPS. Profile the server and look at the Sources view before deleting anything based on the number.

Does each plugin need extra RAM?

Most need very little, but a few hold a lot of data in memory, such as block loggers and map renderers. Watch the memory figure on your usage card rather than budgeting per plugin, and give yourself headroom rather than running at your limit.

Will removing a plugin delete my players' data?

It can. Permission, economy and land claim plugins store data in their own folder or in a database, and that data is useless without them. Take a backup first, and keep the plugin's folder even after you delete its jar.

Why did my server get slow after I added one small plugin?

Because size is not cost. A tiny plugin that listens to player movement and does a lookup on each event can outweigh a large plugin that only runs when someone types a command. Profile with it in place and check the Sources view.

Still stuck? Jump into our Discord at discord.gg/GuavaHost and the team will help you out.

• plugins
• mods
• tps
• lag
• minecraft

Host a Minecraft Java server From $3.99/mo, with instant setup and DDoS protection.

Still need help? Our team is online 24/7 to answer questions.

Contact support