Sharding Solves One Problem and Creates Five Others

Sharding solves a specific problem: a single database instance can't handle the write volume anymore. It doesn't help with slow queries caused by missing indexes, doesn't help with a schema that's grown unwieldy, and doesn't help with read load, which a read replica handles with far less disruption. Profile what's actually failing before reaching for sharding. Teams that shard to fix a problem sharding doesn't address end up with all of sharding's complexity and none of the relief they expected.

The shard key determines which rows land together, and a mismatched key is the single most common sharding mistake: choosing customer ID when most queries actually filter by region, or choosing a key that produces wildly uneven data distribution because a small number of values, one enormous customer, one popular region, account for a disproportionate share of the data. Trace your actual query patterns before picking a key, not the field that seems like the obvious identifier.

Any query that needs data from more than one shard, a report spanning all customers, a join across entities that landed on different shards, gets meaningfully more expensive and more complex to write correctly. This isn't a one-time migration cost, it's an ongoing tax on every feature that needs cross-shard access for the life of the system. Inventory which of your current queries would become cross-shard before committing to a key, since that list tells you the real ongoing cost, not just the migration effort.

A poorly chosen key can concentrate a disproportionate share of traffic onto one shard, recreating the exact bottleneck sharding was supposed to solve, just now with the added complexity of a distributed system on top. Watch per-shard load after any sharding rollout, not just aggregate throughput across all shards combined, since an average that looks healthy can hide one shard running hot while others sit nearly idle.

Data distribution shifts over time even with a well-chosen key, and eventually shards need rebalancing, moving data between them without downtime. Design and test that rebalancing mechanism before the first shard actually gets hot, not as an emergency response once it does: a rebalancing process built under pressure, during a live capacity problem, is exactly the kind of high-stakes, untested migration most likely to introduce data loss or extended downtime.

Shard when write throughput on a single instance is the confirmed, measured bottleneck, when a read replica and query optimization have already been tried and aren't enough, and when the team has mapped which queries will become cross-shard and accepted that ongoing cost. Stay on a single instance, scaled vertically or with read replicas, when any of those three isn't true yet, even if the word 'sharding' has started coming up in every capacity planning conversation.

Shard only when all of these are true:

• Write throughput on a single instance is the confirmed, measured bottleneck, not an assumption.
• A read replica and query optimization have already been tried and aren't enough.
• The team has mapped which queries will become cross shard and accepted that ongoing cost.
• A rebalancing mechanism has been designed and tested before the first shard actually needs it.

Say a team ships a sharding migration, moves all the data, and declares it complete once the application is reading and writing against the new shards correctly. Three months later, a monthly reporting job that nobody remembered still runs a query assuming single-database access, and it starts silently returning incomplete results instead of failing loudly. Inventory every scheduled job, batch process, and analytics query against the shard migration checklist, not just the live application paths, since the ones that run rarely are exactly the ones most likely to get missed.