Before You Shard Your Database, Try Everything Else First

Sharding fixes write throughput and total data volume that a single instance can't handle, by spreading the load across multiple instances. It doesn't fix a slow query caused by a missing index, or a database doing double duty as both your transactional store and your analytics warehouse, both of which are common root causes that look like a scaling problem but aren't actually one sharding solves.

Diagnose the actual bottleneck before reaching for sharding. A database that's slow because of unindexed queries will still be slow after sharding, just distributed across more instances, which makes the underlying problem harder to find, not easier.

Read replicas handle a read-heavy bottleneck at a fraction of the operational complexity of sharding, since they don't require picking a shard key or rewriting your data access layer to route queries. If your bottleneck is read load, not write load, replicas are almost always the right first move.

Splitting genuinely distinct workloads onto separate databases, moving analytics queries off the same instance handling live transactional traffic, for instance, often resolves what looks like a capacity problem without touching your core data model at all. Only reach for sharding once you've confirmed the bottleneck is specifically write throughput or data volume on a single logical dataset that can't be split apart by workload.

Rule these out, in roughly this order, before you shard:

1. Fix indexing first, since a slow query caused by a missing index is not a sharding problem.
2. Add read replicas if your bottleneck is read load, which avoids picking a shard key or rewriting your data access layer.
3. Split distinct workloads, such as transactional and reporting traffic, onto separate databases.
4. Try the largest available single instance with proper indexing before concluding that one instance can't handle your write volume or data size.

The shard key determines how data spreads across instances, and a poor choice creates hot shards, one instance handling far more traffic than the others because the key doesn't distribute evenly. A common mistake is sharding by a customer ID when a handful of large customers generate most of the traffic, concentrating load right back onto a small number of shards instead of spreading it.

Changing a shard key after the fact means re-migrating your entire dataset, which is exactly why it deserves more upfront analysis than almost any other decision in this process. Model your actual traffic distribution against candidate keys before committing, not just your data distribution, since a key that spreads data evenly can still concentrate traffic unevenly.

Any query that needs to join or aggregate across shards, a report spanning all customers, a search that isn't scoped to a single shard key, gets meaningfully harder and slower once your data is split. These queries either need to fan out across every shard and merge results in application code, or require a separate system, a read-only aggregated store, built specifically to answer them.

Inventory your actual query patterns before sharding, not just your write patterns. A team that discovers its most important reporting query needs to span every shard, after sharding is already in production, is solving a much harder problem than the one it started with.

Shards don't stay balanced forever. Traffic grows unevenly, some shards fill up faster than others, and rebalancing, moving data between shards without downtime, is genuinely difficult operational work that most teams underestimate until they're doing it for the first time under pressure.

Budget for rebalancing as an ongoing operational cost from the start, not a one time migration event. Choose a sharding scheme and tooling that supports online rebalancing if you can, since a scheme that requires downtime to rebalance will eventually force that downtime during a period of real growth, which is the worst possible time to take it.