Database Sharding

Database sharding is a horizontal scaling technique that splits a dataset into pieces called shards and spreads them across separate database servers. Each shard holds a subset of the rows, chosen by a shard key.

Why it matters

A single server eventually hits limits on disk, memory, or write throughput. Sharding lets capacity grow by adding servers. It adds real complexity: cross-shard joins and transactions become hard, rebalancing data is disruptive, and a poorly chosen key creates hot spots. Most teams delay it until simpler options like indexing, caching, and replicas are exhausted.

Example

shard = hash(user_id) % 4

user_id 1001 -> shard 1
user_id 1002 -> shard 2
user_id 1003 -> shard 3

All data for one user lives on one shard, so common queries touch a single server.

Common mistakes

• Choosing a shard key with uneven distribution, so one shard takes most of the traffic.
• Sharding too early, long before a single well-tuned server is the bottleneck.
• Forgetting that queries without the shard key must be sent to every shard.

Related

• Database partitioning
• Database replication
• CAP theorem

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.