A single database primary can only accept so many writes per second before disk I/O, write-ahead log flush throughput, and row-lock contention become the hard limit — no amount of query tuning moves that ceiling higher. Sharding solves this by splitting a table's rows across multiple independent database instances, each one a full read-write primary for its own slice of the data. Instead of one machine absorbing every insert and update, N machines each absorb roughly 1/N of the load, and total write capacity scales close to linearly with the number of shards. This is fundamentally different from a read replica, which copies data but still funnels every write through the same original primary. Done deliberately, sharding is the only mechanism that scales write throughput past what a single machine's hardware allows.
What changed in 2026
- Managed sharding layers matured further. Vitess, Citus, and CockroachDB now handle shard rebalancing and query routing automatically, so few teams hand-roll a sharding proxy from scratch anymore.
- Bigger single-node instances raised the bar. Multi-terabyte RAM and NVMe arrays pushing well past 100k IOPS moved the point where sharding becomes necessary considerably further out than a few years ago.
- Native partitioning became the default first step. Postgres declarative partitioning now commonly splits write load across partitions on one machine before a team ever splits across separate machines.
- Online resharding is standard. Adding shards without downtime, once the scariest part of the whole exercise, is a built-in operation in Vitess and CockroachDB.
Why writes specifically run out of room
Every write on a relational primary goes through the same choke points: the write-ahead log must be flushed before a transaction can commit, and any row being updated concurrently is serialized behind a lock. A read replica adds read capacity, but every write — from every application server, through every replica's own connection — still lands on that one primary's WAL. Vertical scaling helps up to a point: a bigger instance means faster disks and more memory for buffering. But disk write bandwidth and lock contention on hot rows do not scale just because you added CPU cores. Sharding is the only lever that adds independent write paths, because each shard has its own WAL, its own disks, and its own lock manager.
Shard key strategies and how writes distribute
| Shard key strategy |
How writes distribute |
Main risk |
| Hash of user_id / tenant_id |
Even, near-random across shards |
Cross-shard aggregate queries get harder |
| Range (id ranges, created_at) |
Uneven — new rows always land on the newest shard |
Hot shard on whichever range is currently active |
| Geographic / region |
Even only if users are evenly distributed |
One dominant region overloads its shard |
| Directory (lookup table) |
Fully controllable, manually balanced |
Extra hop and a single point of failure on the lookup |
-- Hash-based routing: the application computes the shard before connecting
shard_id = hash(tenant_id) % num_shards
-- Route the write to shards[shard_id] as a normal SQL statement
INSERT INTO orders (tenant_id, total_cents) VALUES ($1, $2);
A hash key on a high-cardinality column is the safest default. Range keys are simpler to reason about but concentrate write load on one "hot" shard unless you actively rotate which shard receives new data.
Common mistakes
Sharding by a low-cardinality or skewed column. Sharding by plan_tier when 95% of accounts are on the free tier just moves the entire write load onto one shard — you have added operational complexity without adding write capacity.
Allowing cross-shard writes in the hot path. A single logical operation that must write to two shards atomically needs two-phase commit or a saga pattern. Both add latency that most request paths cannot absorb; design schemas so related rows written together live on the same shard.
Sharding before fixing the real bottleneck. An oversized transaction or a missing index is still slow on each shard individually. Sharding turns one slow database into several slow databases; profile with EXPLAIN ANALYZE before assuming you need to shard at all.
Picking a fixed shard count with no rebalancing plan. Outgrowing your shard count without an online resharding strategy means a full migration project later, under more time pressure than if you had planned for it from the start.
FAQ
Does sharding help a read-heavy application?
Not directly — read replicas solve read scaling with far less complexity. Reach for sharding when writes, not reads, are the bottleneck.
How many shards should I start with?
Most teams start somewhere between 4 and 16. Fewer shards keeps operations simple; more shards gives more room to grow before the next resharding event.
Can I shard just one table instead of the whole database?
Yes, and it is a common pattern — shard the one table taking the write volume, such as events, orders, or messages, while keeping smaller reference tables on a single instance.
What happens to foreign keys and joins across shards?
Distributed databases generally cannot enforce cross-shard foreign keys or execute efficient cross-shard joins. Denormalize the data you need together, or resolve the join in application code.
Where to go next
See read replicas explained for 2026 if writes are not actually your bottleneck, check database migration strategies for 2026 for changing schema safely once you run multiple shards, and use how to pick a database in 2026 to decide whether you need this level of complexity at all.