A shard is one connection to Discord handling a portion of your servers. Below a certain size you need exactly one and should not think about this at all; past it, Discord requires you to split, and a few things about your bot have to change.
The threshold
Discord requires a bot to shard once it is in 2,500 servers or more. That is a hard requirement rather than a suggestion — the connection will be refused without it. Below that number, a single shard is correct and adding more only adds complexity.
What changes when you shard
| Thing | Before | After |
|---|---|---|
| Connections to Discord | One | One per shard |
| Memory | One process | Usually one process per shard, or one manager spawning them |
| Getting a server by id | Immediate | It may live on another shard |
| Counting total users | A property | A query across shards that you have to aggregate |
| Restarting | One process | Rolling, if you want to avoid full downtime |
Anything that assumed your bot could see every server at once stops being true. A /stats command that counts guilds, a global announcement, a lookup by user id — all of these need to ask every shard and combine the answers. That is the real migration work, and it is worth writing those commands defensively long before you reach the threshold.
If you are approaching it
- Use your library's shard manager
Both major libraries have one. Writing your own process orchestration is a solved problem you do not need to re-solve.
- Audit anything that iterates over all guilds
Those are your future bugs. Find them while the bot is still small enough that they work by accident.
- Plan memory per shard, not in total
Each shard holds its own cache. Sharding does not reduce memory use; it distributes it, and often increases the total.
- Test with two shards long before you need many
Forcing two shards locally surfaces every cross-shard assumption immediately, with no traffic and no stakes.
Bots lag or run out of memory for ordinary reasons — a leak, an expensive loop, too much cache. Sharding a small bot to fix performance adds moving parts and fixes nothing, because the bottleneck was never the number of connections.