Scale Vertically First, Shard Later
Both can be right, but when time is of the essence, almost always scale vertically first:
Scale Vertically First
- Bigger instance = more CPU, RAM, faster disk
- Zero application changes
- Takes 10 minutes on RDS
- Buys you time to think clearly
Do this until it stops working or becomes nonviable economically.
When Sharding Actually Makes Sense
Then consider sharding, but only if:
-
Your dataset genuinely won't fit on a single node. We're talking 10TB+ and if you're not there, you're not ready.
-
Write throughput is the bottleneck, not read throughput. Read scaling = read replicas. Sharding for reads is almost always the wrong answer.
-
Your access patterns are partition-friendly. If every query needs data across shards, sharding makes things slower... not faster.
-
Your team can operationally handle it. Cross-shard transactions, re-balancing, hot-spot management. This is not a weekend project.
The Hidden Cost Nobody Talks About
Sharding adds permanent complexity to every query, every migration, and every engineer who joins your team.
That's a tax you pay forever.
Read replicas, connection pooling, query optimisation, and a vertical upgrade will solve 90% of database scaling problems.
Shard when you have no other choice, not because it sounds like the right answer.
If your database is becoming a bottleneck and you're not sure which direction to take it, let's talk through it.