Should you add read replicas or shard when the database is slow?
Add read replicas when reads dominate, since they scale reads cheaply. Shard when writes or data size exceed one machine. Check indexes, queries and caching before either.
Explain it simply
A slow database has different causes, and each fix addresses one.
First look cheap: missing indexes, slow queries, no caching, connection pool limits. Many problems vanish here.
Read replicas help when most traffic is reads, like a product catalogue that is browsed far more than it is updated. Each replica adds read capacity, and the app sends reads to replicas and writes to the leader. It does not help write volume or total data size, because every replica holds all the data and applies every write.
Sharding helps when:
- Writes exceed what one leader can apply.
- The dataset no longer fits on one machine.
- Even the largest affordable server is saturated.
It costs a lot in complexity: routing, cross-shard queries, transactions, rebalancing.
Order of escalation: tune queries and indexes, add caching, scale vertically, add read replicas, then shard.
Example
Diagnosing an e-commerce database:
Reads 95%, writes 5%, data 200 GB -> add read replicas + cache
Writes 20,000/s, leader CPU at 95% -> shard (replicas will not help)
Data 15 TB and growing -> shardWhat to say in the interview
"Replicas scale reads and availability; sharding scales writes and storage. I would first fix queries and indexes, add a cache, scale up, then add replicas, and only shard when writes or data volume demand it."