Sharding is the practice of splitting a database horizontally across several independent servers, called shards, so that each shard stores only a subset of the rows and handles only part of the traffic. A shard key, such as a customer or tenant identifier, decides which shard holds each row. In database performance, sharding is the main way to scale writes and storage beyond one machine.
Replication copies the same data to more servers and mostly helps reads; sharding divides the data itself, so total capacity grows with the number of shards. That gain comes with real costs: cross-shard queries, distributed transactions and rebalancing become problems the system or the application must solve.
How sharding distributes data
Every sharded system has three parts: the shards that store data, a routing layer that sends each query to the right shard, and metadata that maps key values to shards. The router may live in a proxy, in a database coordinator node or directly in the application through a sharding-aware library.
Queries that include the shard key go to one shard, which is fast and scales well. Queries without it must be sent to all shards and merged, a pattern called scatter-gather, whose latency is set by the slowest shard. Good sharding design keeps the most frequent queries single-shard.
The table below compares the main strategies for mapping keys to shards.
| Strategy | How rows are assigned | Main trade-off |
|---|---|---|
| Range sharding | Contiguous key ranges per shard | Efficient range scans, risk of hot ranges |
| Hash sharding | Hash of the key decides the shard | Even spread, range queries hit all shards |
| Consistent hashing | Keys and nodes placed on a hash ring | Moves little data when nodes change |
| Directory-based | Lookup table maps keys to shards | Flexible placement, extra lookup and dependency |
| Geographic | Region or country decides the shard | Data residency and locality, uneven sizes |
Choosing a shard key
The shard key is the most consequential decision in a sharded design, because changing it later usually means moving all data. A good key spreads data and load evenly and matches the way the application accesses data.
| Property | Why it matters | Warning sign |
|---|---|---|
| High cardinality | Allows data to spread over many shards | Key with only a few distinct values |
| Even frequency | Prevents oversized shards | One tenant holds most of the data |
| Non-monotonic writes | Avoids all inserts landing on one shard | Timestamp or auto-increment key with range sharding |
| Query alignment | Keeps common queries on one shard | Frequent queries without the key |
| Stability | Rows rarely need to move | Key values that change over time |
Multi-tenant applications often shard by tenant identifier, because nearly every query is scoped to one tenant. Very large tenants then become hot spots, which systems handle by giving them dedicated shards or by using a compound key such as tenant plus user.
Sharding compared with partitioning and replication
Sharding is often confused with partitioning and replication. The three techniques answer different questions and are frequently combined, for example with each shard replicated for high availability.
| Technique | What is split or copied | Primary benefit |
|---|---|---|
| Sharding | Rows split across separate servers | Scales writes, storage and throughput |
| Partitioning | Rows split inside one database server | Faster maintenance and partition pruning |
| Replication | Whole dataset copied to other servers | Read scaling and failover |
| Vertical scaling | Nothing, one larger server | Simplicity with no distribution logic |
Because sharding adds permanent complexity, experienced teams first exhaust cheaper options: query optimization, indexing, connection pooling, caching, read replicas and larger hardware. A single modern server can handle a very large workload, so sharding is justified when one primary can no longer absorb the write rate or data volume, not merely when traffic grows.
Rebalancing, transactions and cross-shard queries
Data does not stay evenly distributed. Rebalancing moves chunks or key ranges between shards as shards grow or new servers join. Systems like MongoDB and Vitess move data in the background, while hand-built schemes often require planned migrations with dual writes and verification.
Transactions that touch several shards need a distributed commit protocol, typically two-phase commit, which adds network round trips and failure modes. Many sharded applications therefore design their data so that each business transaction stays within one shard.
Joins across shards, global unique constraints and globally sorted pagination are expensive or unavailable. Common workarounds include duplicating small reference tables on every shard, generating identifiers without a central sequence, and sending analytical queries to a separate data warehouse fed from all shards.
Operations also multiply. Schema migrations, backups, monitoring and failover must run on every shard consistently, and a migration that succeeds on most shards but fails on one leaves the cluster in a mixed state. Automation and per-shard health dashboards are therefore part of any serious sharded deployment.
Common sharding mistakes
Sharding failures are rarely about the mechanism and mostly about choices made too early or too late. The table summarizes frequent problems.
| Problem | Cause | Remedy |
|---|---|---|
| Hot shard | Skewed or monotonic shard key | Hash the key or split heavy tenants |
| Slow fan-out queries | Frequent queries lack the shard key | Redesign queries or add a lookup index |
| Painful resharding | Fixed modulo mapping to shard count | Use many logical shards mapped to fewer servers |
| Inconsistent data | Cross-shard writes without coordination | Keep transactions single-shard or use sagas |
| Premature complexity | Sharding before it was needed | Scale vertically and optimize first |
Creating many logical shards, for example 256 or 1,024, and mapping them onto a few physical servers is a widely used technique, because growth then means moving whole logical shards instead of rehashing every row.
In plain words
Sharding is like a large library that splits its collection across several buildings: authors A to F in one building, G to M in the next, and so on. Each building has its own staff, so many visitors can be served at once.
Finding one author is quick, because you know which building to visit. A question that involves every author, however, means visiting every building and combining the answers, which takes longer and needs careful coordination.
A real-world example
A software company hosts a project management service for thousands of business customers on one PostgreSQL primary. After years of growth, write load and table sizes approach the limits of the largest server available, and maintenance jobs take hours.
The team shards by tenant identifier into 128 logical shards spread over eight database servers, with a routing layer that looks up each tenant’s shard. Because nearly every request concerns a single tenant, almost all queries stay on one shard. Two very large customers receive dedicated servers, and company-wide reporting moves to a warehouse that collects data from all shards each night.