Sharding splits one logical database across several physical ones so that no single machine holds everything. It is genuinely necessary at sufficient scale and it is also reached for far too early, by teams whose actual problem is a missing index or a query pattern that would be fine on a read replica.
Before sharding, be certain the alternatives are exhausted, because the shard key you choose is close to permanent.
What changed in 2026
- Vertical limits kept rising. Single-instance capacity continued growing, which pushed the threshold at which sharding becomes necessary further out.
- Managed sharding matured. Database platforms handling shard distribution and rebalancing reduced the operational burden, without changing the shard key decision.
- Resharding tooling improved. Online resharding became more practical, though still a substantial project rather than a configuration change.
- Application-level complexity stayed the real cost. Recognition that the hard part is query patterns and transactions rather than infrastructure remained consistent.
Try these first
| Option |
Handles |
| Better indexing and query optimization |
A surprising share of apparent scaling problems |
| Vertical scaling |
Higher than most teams assume |
| Read replicas |
Read-heavy workloads entirely |
| Caching |
Repeated reads of the same data |
| Archiving cold data |
Table size when most rows are never queried |
| Splitting by table into separate databases |
Independent workloads sharing an instance |
| Sharding |
Genuine write-throughput or data-volume limits |
Each row above sharding is cheaper, reversible, and less invasive. Working through them honestly frequently ends the conversation, and when it does not, you arrive at sharding knowing why.
Choosing the shard key
The key determines which shard a row lives on, and everything about the system's behaviour follows from it.
Distribution. The key must spread data and traffic evenly. A key correlated with activity — a customer identifier where one customer generates most of the volume — produces a hot shard doing all the work while others idle.
Query alignment. Most queries should be answerable from one shard. If the common query pattern requires consulting every shard, you have added latency and complexity without reducing per-query work.
Stability. The key must not change for a given row. Changing it means moving the row between shards, which is a distributed operation nobody wants in a hot path.
Cardinality. Enough distinct values to distribute across shards now and after future growth. A key with few values caps how many shards you can have.
Tenant identifier is the common choice in multi-tenant systems because it aligns with query patterns naturally — most queries are scoped to one tenant. Its weakness is distribution, since tenant sizes vary enormously, and large tenants may need dedicated shards.
Hashing an identifier gives excellent distribution and destroys range queries, since adjacent values land on different shards.
What you give up
Cross-shard joins become application-level work or are unavailable. Cross-shard transactions require distributed coordination or a saga, as in saga pattern explained. Aggregate queries touch every shard. Unique constraints across shards need a separate mechanism.
Plan for these explicitly rather than discovering them, because the design that emerges is shaped by which of them you can avoid — which is really a question about the shard key, again. The related detail of key design within a shard is in partition key design.
Common mistakes
- Sharding before exhausting simpler options. Permanent complexity for a solvable problem.
- A shard key correlated with traffic. Hot shard doing all the work.
- A key that can change. Row migration in the hot path.
- Ignoring cross-shard query patterns. Discovered after the key is fixed.
- Too few shards initially. Resharding sooner than expected.
- No plan for uneven growth. One tenant outgrowing its shard.
FAQ
How do I know I need sharding?
When write throughput or data volume exceeds what a well-tuned single instance with replicas can handle. Measure rather than assume.
Can I change the shard key later?
Technically yes, practically it is a major migration involving moving most of your data. Choose carefully.
Should I use a managed sharded database?
It removes operational burden and does not remove the shard key decision or the application-level consequences.
What about consistent hashing?
It reduces how much data moves when adding shards, which is valuable. It does not address query alignment.
Where to go next
For key design details, read partition key design. For cross-shard transactions, saga pattern explained, and for connection management at scale, connection pooling explained.