When a single MySQL server can no longer handle write throughput even with good indexing and hardware, sharding splits data horizontally across multiple independent database servers — a significant architectural jump, not a first-line optimization.
How Sharding Works
Rows are distributed across shards based on a shard key (often a customer ID or a hash of it) — customer 1-1000 lives on shard A, 1001-2000 on shard B, and so on. Each shard is a complete, independent MySQL instance.
function getShardForCustomer(int $customerId): PDO {
$shardIndex = $customerId % NUM_SHARDS;
return getConnectionForShard($shardIndex);
}
The Real Cost
- Cross-shard joins and transactions become genuinely hard or impossible
- Rebalancing shards as data grows unevenly is an operational project, not a config change
- Every piece of application code touching the database needs shard-awareness
Before sharding, exhaust simpler options first: better indexing, read replicas, caching, and vertical scaling (bigger hardware) — sharding solves a real problem but introduces enough complexity that it should be a last resort, not a default architecture.