Database Sharding: System Design Series

Mohit Salvi

4 min read

·

Aug 27, 2026

--

Listen

Share

As applications grow, the database often becomes one of the biggest bottlenecks.

You can scale your application servers horizontally by simply adding more instances. But what happens when a single database server can no longer handle the growing amount of data and traffic?

One common solution is Database Sharding.

Press enter or click to view image in full size

What is Database Sharding?

Database sharding is a technique where a large database is split into smaller pieces called shards.

Each shard stores a portion of the data, and these shards are distributed across multiple database servers.

For example, imagine we have 100 million users.

Instead of storing everything on one database:

           Database
          100M Users
              |
       ┌──────┼──────┐
       ↓      ↓      ↓
    Shard 1 Shard 2 Shard 3
    0-33M   34-66M   67-100M

Now, each database server handles only a part of the overall data.

This reduces the load on individual servers and allows the system to scale horizontally.

How Does Sharding Work?

The most important decision in sharding is choosing a shard key.

The shard key determines where a particular record will be stored.

For example, if user_id is the shard key, we could use:

shard = user_id % number_of_shards

So:

user_id = 101 → Shard 1
user_id = 102 → Shard 2
user_id = 103 → Shard 3

The application or a routing layer can then determine which shard should receive the request.

Choosing a good shard key is extremely important. A poor choice can result in some shards receiving far more traffic or data than others.

Common Sharding Strategies

1. Range-Based Sharding

Data is divided into ranges.

Shard 1 → user_id 1 - 1M
Shard 2 → user_id 1M - 2M
Shard 3 → user_id 2M - 3M

It’s simple and easy to understand, but traffic can become uneven if most new records fall into the same range.

2. Hash-Based Sharding

A hash function determines the shard.

hash(user_id) % N

This generally distributes data more evenly, but changing the number of shards can become difficult because many records may need to move.

3. Consistent Hashing

Consistent hashing reduces the amount of data that needs to move when shards are added or removed.

This makes it useful for systems that need to scale dynamically.

What Problems Does Sharding Solve?

Sharding primarily helps with horizontal database scaling.

Instead of continuously making one database server bigger, we can add more database servers.

It can help with:

• Handling very large datasets
• Increasing database throughput
• Reducing load on individual servers
• Scaling storage horizontally
• Improving availability when designed correctly

But sharding isn’t a magic solution.

The Hard Part: Distributed Queries

Once data is spread across multiple databases, queries can become more complicated.

Suppose we want:

SELECT * FROM orders
WHERE user_id = 101;

If user_id is the shard key, we know exactly where to look.

But what about:

SELECT * FROM orders
WHERE order_status = 'pending';

We may not know which shard contains the required data.

The system might need to query every shard and combine the results.

This is called a scatter-gather query, and it can become expensive as the number of shards increases.

Sharding vs Replication

It’s easy to confuse the two.

Replication usually means creating copies of the same data across multiple database servers.

Primary
  ↓
Replica
  ↓
Replica

Replication is mainly useful for availability and read scaling.

Sharding splits the data itself:

Shard 1 → Users A-C
Shard 2 → Users D-F
Shard 3 → Users G-Z

Sharding is mainly about scaling data and write capacity horizontally.

In real-world systems, both are often used together.

For example, each shard may have its own replicas:

Application
                  |
        ┌─────────┼─────────┐
        ↓         ↓         ↓
      Shard 1   Shard 2   Shard 3
       /  \       /  \       /  \
      P    R     P    R     P    R

The Biggest Challenge: Choosing the Right Shard Key

A good shard key should ideally:

• Distribute data evenly
• Distribute traffic evenly
• Be present in common queries
• Avoid creating a single hot shard

For example, sharding by country might look attractive, but if one country has significantly more users than others, that shard could become overloaded.

A good sharding strategy isn’t just about splitting data.

It’s about splitting the workload intelligently.

Final Takeaway

Database sharding becomes useful when a single database can no longer comfortably handle the application’s data, traffic, or write workload.

But it also introduces distributed-system problems:

More scalability → More complexity

You now have to think about routing, shard keys, distributed queries, rebalancing, transactions, and data movement.

That’s why sharding is usually not the first optimization.

Start with indexing, query optimization, caching, vertical scaling, and replication.

When those approaches are no longer enough, sharding can become the next step toward building a database that scales horizontally.