MongoDB Sharding

What Is MongoDB Sharding?

Sharding distributes data across multiple machines. MongoDB uses it for very large datasets and high-throughput workloads that outgrow a single server.

One server
    ↓
Limited storage / CPU / workload capacity

Multiple shards
    ↓
Data + workload distributed across servers

Instead of only making one server bigger, distribute the workload across multiple servers—horizontal scaling.

Why Use Sharding?

Sharding adds infrastructure and operational complexity. If a dataset fits comfortably on a single server (or a single replica set), an unsharded deployment may be the better choice.

Horizontal Scaling vs. Vertical Scaling

Vertical Scaling

      Bigger Server
   ┌───────────────┐
   │ More CPU      │
   │ More RAM      │
   │ More Storage  │
   └───────────────┘


Horizontal Scaling

   Server 1    Server 2    Server 3
      ↓           ↓           ↓
   Data A      Data B      Data C

MongoDB sharding is horizontal scaling: each shard handles a subset of the data and work.

What Is a Sharded Cluster?

A sharded cluster has three core pieces: shards, mongos routers, and config servers.

                 Application
                      |
                      v
                   mongos
                 Query Router
                /     |      \
               v      v       v
            Shard 1 Shard 2 Shard 3
             /          |          \
          Replica     Replica     Replica
           Set         Set         Set

                 Config Servers
                       |
                       v
              Cluster Metadata

Shards

Each shard stores a subset of the sharded data. Each shard must be deployed as a replica set for redundancy and availability.

mongos

mongos is the query router between applications and the cluster. Clients should connect to mongos for cluster-level operations.

Config servers

Config servers store cluster metadata and configuration that mongos uses for routing. They are deployed as a replica set (CSRS).

How MongoDB Sharding Works

Application
     |
     v
  mongos
     |
     | Uses shard key / routing metadata
     |
     +----------+----------+
     |          |          |
     v          v          v
  Shard 1    Shard 2    Shard 3

1. The application sends a request to mongos.
2. mongos determines which shard(s) may hold the data.
3. The request goes to the appropriate shard(s).
4. Results return through mongos.
5. The application receives the result.

Connect to mongos for normal cluster reads and writes—not directly to a single shard.

What Is a Shard Key?

A shard key is a field or combination of fields that MongoDB uses to distribute documents across shards.

{
  _id: 1,
  userId: 1001,
  name: "Laptop",
  price: 75000
}

// Possible shard key:
{ userId: 1 }

• The shard key influences where documents are stored.
• It also affects how queries can be routed.
• Choosing a good key is critical for balance and performance.
• A poor key can cause uneven distribution or inefficient queries.

Shard Key Example

db.orders.insertMany([
  { userId: 101, total: 500 },
  { userId: 202, total: 800 },
  { userId: 303, total: 300 }
])

// Shard key:
{ userId: 1 }

How It Works

1. MongoDB examines each document’s shard-key value (userId).
2. That value determines placement within the sharded collection.
3. Routing uses shard-key information when queries include it.
4. Exact placement depends on strategy (ranged/hashed) and cluster state.

Chunks

MongoDB partitions sharded data into chunks—ranges of shard-key values with an inclusive lower bound and exclusive upper bound.

Shard Key Range

0 ─────── 100
101 ───── 200
201 ───── 300
301 ───── 400

       ↓

     Chunks
       ↓
 distributed across shards

• A chunk covers a range of shard-key values.
• Chunks are distributed across shards.
• MongoDB can move ranges between shards to balance data.

Balancer

The balancer runs in the background and migrates ranges between shards to help keep data appropriately distributed.

Before balancing:

Shard 1 → Many chunks
Shard 2 → Few chunks
Shard 3 → Few chunks

          ↓

      Balancer

          ↓

Shard 1 → Balanced
Shard 2 → Balanced
Shard 3 → Balanced

Balancing is continuous background work—not an instant, perfect rearrange after every write.

Ranged Sharding vs. Hashed Sharding

Neither strategy is always better. Match the strategy to your key pattern and queries.

Ranged sharding

userId 1–1000
userId 1001–2000
userId 2001–3000

Nearby values are more likely to share a range/chunk.

Hashed sharding

userId
  ↓
Hash
  ↓
Hash value
  ↓
Distribution across ranges

Hashed sharding can spread monotonically changing values more evenly, but range queries on the shard key are less likely to target a single shard.

Targeted Queries vs. Scatter/Gather Queries

Targeted query

The query includes the shard key (or an appropriate prefix of a compound shard key).

db.orders.find({
  userId: 101
})

// mongos can route to relevant shard(s)
mongos
  |
  +----> relevant shard(s)

Scatter/gather

The query does not provide enough shard-key information, so mongos may need to query multiple or all shards and combine results.

db.orders.find({
  total: { $gt: 500 }
})

// often needs work across many shards
             mongos
          /     |     \
         v      v      v
      Shard 1 Shard 2 Shard 3

Exact routing depends on the query shape and metadata. The key lesson: include the shard key when you can to help targeting.

Pseudocode

Application sends query
        ↓
mongos receives query
        ↓
Check shard-key information
        ↓
Can the query be targeted?
      /       \
    Yes        No
     ↓          ↓
Target shard   Query multiple shards
     ↓          ↓
        Combine result
             ↓
         Return result

Worked Walkthrough

Small orders collection with shard key { userId: 1 }.

[
  { orderId: 1, userId: 101, total: 500 },
  { orderId: 2, userId: 202, total: 800 },
  { orderId: 3, userId: 101, total: 300 }
]

Shard key: { userId: 1 }

db.orders.find({
  userId: 101
})

How It Works

1. The query is sent to mongos.
2. userId is the shard key.
3. mongos uses that value to find the relevant shard(s).
4. Only those shard(s) need to process the targeted operation.
5. The result returns through mongos.

MongoDB Sharding Examples

Run these from mongosh connected to a mongos in a sharded cluster.

sh.enableSharding("shop")

sh.shardCollection(
  "shop.orders",
  { userId: 1 }
)

sh.shardCollection(
  "shop.orders",
  { userId: "hashed" }
)

sh.status()

db.orders.find({
  userId: 101
})

Zones

Zones associate ranges of shard-key values with specific shards. They can improve data locality (for example across data centers). Zone ranges use inclusive lower and exclusive upper bounds, based on the shard key.

This page only introduces the idea—zone setup belongs on a dedicated guide.

Replication vs. Sharding

MongoDB commonly uses both together: each shard is a replica set, so you get distribution and redundancy.

Sharding vs. Partitioning

In MongoDB, sharding partitions a collection’s documents across multiple shards based on a shard key. Think “split the collection across machines using a key,” not a separate product feature from sharding.

When Should You Consider Sharding?

There is no universal data-size threshold. Workload, hardware, query patterns, storage, and growth all matter. Small datasets that fit one server often gain little from sharding.

Performance Notes

Cheat Sheet

Key Takeaways