MongoDB Sharding
What is Sharding?
Sharding is MongoDB's approach to horizontal scaling. Instead of adding more resources to a single server (vertical scaling), sharding distributes data across multiple servers called shards. Each shard holds a subset of the data, and together they form a single logical database.
A sharded cluster consists of three components:
Shard Key Selection
The shard key determines how data is distributed across shards. Choosing the right shard key is critical — a poor choice leads to uneven distribution (hotspots) or scatter-gather queries that hit all shards.
| Strategy | How it Works | Best For |
|---|---|---|
| Range-based | Documents with adjacent shard key values go to the same shard | Range queries on the shard key |
| Hash-based | A hash of the shard key value determines the shard | Even distribution, write-heavy workloads |
| Zone sharding | Assign specific shard key ranges to specific shards | Geographic data locality, compliance |
// Connect to mongos router
mongosh "mongodb://mongos-host:27017"
// Enable sharding on a database
sh.enableSharding("myapp")
// Shard a collection with a hashed shard key (even distribution)
sh.shardCollection("myapp.users", { userId: "hashed" })
// Shard a collection with a range-based compound shard key
sh.shardCollection("myapp.orders", { customerId: 1, createdAt: 1 })
// Check sharding status
sh.status()
// Check which shard a document would go to
db.users.explain().find({ userId: "user123" })// View chunk distribution across shards
use config
db.chunks.find({ ns: "myapp.users" }).pretty()
// Check balancer status
sh.getBalancerState()
sh.isBalancerRunning()
// Zone sharding — route data to specific shards by region
// Assign a zone to a shard
sh.addShardTag("shard0", "US")
sh.addShardTag("shard1", "EU")
// Define zone ranges for the shard key
sh.addTagRange(
"myapp.users",
{ region: "US", userId: MinKey },
{ region: "US", userId: MaxKey },
"US"
)
sh.addTagRange(
"myapp.users",
{ region: "EU", userId: MinKey },
{ region: "EU", userId: MaxKey },
"EU"
)
// View shard distribution
db.adminCommand({ listShards: 1 })// GOOD shard key characteristics:
// - High cardinality (many unique values)
// - Even distribution of writes
// - Frequently used in queries (avoids scatter-gather)
// BAD shard key examples:
// { status: 1 } — low cardinality (only a few values), creates hotspots
// { createdAt: 1 } — monotonically increasing, all writes go to one shard
// { _id: 1 } — ObjectId is monotonically increasing (use hashed instead)
// GOOD shard key examples:
// { userId: "hashed" } — even distribution for user data
// { customerId: 1, orderId: 1 } — compound, good for customer queries
// { email: "hashed" } — even distribution
// Note: Shard key is IMMUTABLE after sharding
// You cannot change a document's shard key value (MongoDB 4.2+ allows it with limitations)
// Choose carefully before sharding!