Database Sharding Basics: When MySQL Needs to Scale Out

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.