Do I Need to Shard My Discord Bot? Almost Certainly Not Yet

Sharding is a scaling requirement, not a performance tuning knob, and Discord is precise about when it applies: "Each shard can only support a maximum of 2500 guilds, and apps that are in 2500+ guilds must enable sharding" (Discord docs). Below that number, sharding will not make your bot faster, will not reduce its memory, and mostly adds ways for it to break. If your bot is slow or running out of memory in 40 servers, sharding is not the fix. And when you do cross the threshold, the choice that actually matters for a small container isn't whether to shard — it's whether your shards run in one process or several.

What sharding actually splits#

A shard is a gateway connection, and sharding divides which guilds' events arrive on which connection. Discord assigns them deterministically: shard_id = (guild_id >> 22) % num_shards.

That's it. It splits the event stream. It does not split your data, your database, or your cache — and if all your shards live in one process, they share the same memory anyway.

This is why sharding disappoints people who reach for it to fix resource problems. Your bot is not slow because one WebSocket is delivering too many events; it's slow because of what you do with them.

How to know if you need it#

Don't count guilds by hand. Discord's Get Gateway Bot endpoint returns a shards field — "recommended number of shards to use when connecting" — and that's the authoritative answer for your bot right now. Most libraries can call it for you and use the result automatically.

If it says 1, you don't need sharding. Revisit when you're approaching 2500 servers, which is a milestone most bots never reach.

The choice that matters: one process or several#

Here's where hosting comes in, and it's the part general Discord guides skip.

Libraries offer two shapes:

• Internal sharding — one process holds several gateway connections (AutoShardedClient in discord.py, passing a shard list in discord.js).
• Multi-process sharding — a manager spawns one child process per shard (ShardingManager in discord.js).

Multi-process is the default advice in a lot of tutorials, and it's the wrong default on a small container. Each child process is a full copy of your runtime and your libraries before it does anything useful, so four shards means roughly four times the baseline memory — against a RAM limit that's a hard cap, where exceeding it gets the process killed rather than slowed.

The CPU story is worse. Your allocation is a time budget shared across the whole container, so four processes don't get four budgets — they split one, with added scheduling overhead.

On a single small container, use internal sharding. Multi-process sharding is designed for spreading shards across multiple machines, and it earns its complexity only when you actually have several.

Sharding multiplies your identify cost#

Worth knowing before you turn it on, because it interacts with a limit that has a harsh penalty.

Each shard identifies separately. So a 4-shard bot spends four IDENTIFY calls per full startup instead of one — against a ceiling of 1000 per 24 hours, beyond which your token gets reset.

A crash-looping sharded bot therefore burns its daily allowance four times faster. If you shard, be even more disciplined about stopping a bot that's restarting rather than letting it loop while you investigate.

Startup also gets slower: shards start in batches governed by max_concurrency, which is 1 for most bots, so shards come up in sequence rather than all at once.

What to fix instead#

If you're hitting resource limits well below 2500 guilds, the cause is almost always cache, and that's where the wins are:

• Turn off member caching if you don't need it. Caching every member of every guild is the single largest memory consumer in most bots, and most bots use almost none of it.
• Request only the intents you use. Fewer intents means fewer events and less cached state — and privileged intents have their own gate.
• Don't keep message history in memory. If you need it, it belongs in a database.
• Check whether it's actually CPU. Slow commands are more often a blocking call in an async handler than a lack of resources.

Any of these will do more for a 500-guild bot than sharding, and none of them add moving parts.

Be realistic about what a big bot needs#

Honest note, because there's no point pretending otherwise: a bot in 2500+ servers is not a small-container workload. It holds more state, receives far more events, and does more database work. Sharding is what Discord requires of it, not what makes it cheap.

If you're genuinely approaching that scale, plan for a real allocation and check what your account limits allow — and get your cache discipline right first, because at that size every megabyte per guild is multiplied by thousands.

For completeness: past 150,000 guilds Discord assigns a shard multiplier and raises your session limits accordingly. If that's you, this post is not the one you need.

FAQ#

When do I have to shard my Discord bot?#

At 2500 guilds. Discord requires sharding for apps in 2500+ servers; below that it's optional and rarely useful.

Will sharding make my bot faster?#

No. It splits the gateway event stream, not your processing. Slowness is nearly always your handlers or your cache.

Does sharding reduce memory usage?#

Not on one machine. Shards in one process share memory, and separate processes each carry a full runtime copy — which increases total usage.

Internal or multi-process sharding?#

Internal, on a single container. Multi-process sharding exists to spread shards across machines and costs you a full runtime per shard otherwise.

How do I know how many shards I need?#

Call Get Gateway Bot and read the recommended shards value. Most libraries do this automatically.

Does sharding affect rate limits?#

Yes — each shard identifies separately, so a sharded bot consumes its daily IDENTIFY allowance proportionally faster.

Wrapping up#

Sharding has a reputation as the thing you do when your bot gets popular, which makes it sound like an optimisation. It isn't — it's a requirement that arrives at a specific size, and it costs you startup time, identify budget, and complexity in exchange for satisfying it. Below 2500 guilds, trim your cache and check your handlers. Above it, shard internally in one process until you genuinely have more than one machine to spread across.