Read Replicas vs. Database Sharding: They Solve Different Problems
- By Manaswini De • Software Engineer & Instructor at CodeKerdos
“Our database is struggling, so let’s add read replicas” and “Our database is struggling, so let’s shard it” get thrown around in design interviews and architecture reviews almost interchangeably – as if they were two flavors of the same fix. They aren’t.
Read replicas and sharding both live under the umbrella of “database scaling,” and that’s exactly where the confusion starts. One scales how much you can read. The other scales how much you can write and store. Reach for the wrong one, and you’ll add a pile of operational complexity while your actual bottleneck doesn’t move at all.
The One-Database Ceiling
Every scaling conversation starts from the same place: a single primary database handling every read and every write for the whole application.
Figure 1 – More app servers don’t help if they’re all still queuing at the same single database.
This works beautifully until it doesn’t – and “it doesn’t” shows up as one of two distinct symptoms: either the database is drowning in read queries while writes stay light, or the database can’t keep up with the volume (or sheer size) of writes no matter how few reads you throw at it. Those are different diseases, and they need different medicine.
Read Replicas: Scaling How Much You Can Read
A read replica is a live, continuously-updated copy of your primary database. The primary still handles every write; replicas subscribe to a stream of changes and apply them locally, so they stay (nearly) in sync while serving read traffic independently.
Figure 2 – Writes still funnel through one primary; reads fan out across as many replicas as you add.
This is a genuinely powerful lever when your traffic is read-heavy – product catalogs, social feeds, dashboards, anything where people look at data far more often than anyone changes it. Add a replica, and you’ve added read capacity. Add three more, and you’ve quadrupled it, with no changes to your schema or your application logic beyond routing reads to a different connection.
The Catch: Replication Lag
Replication is asynchronous by default, which means there’s always a small window where a replica is telling the truth about a moment ago, not right now.
Figure 3 – A write and an immediate read of that same data can land on different sides of the replication gap.
Worth Remembering
This is why “user updates their profile, then the page reloads and shows the old data” is such a common bug report right after a team adds read replicas. The fix isn’t exotic – route read-your-own-write scenarios back to the primary, or read from the replica that’s caught up – but it’s a real design decision, not a detail you get for free.
What Read Replicas Don't Solve
It’s worth being explicit about the limits, because this is exactly where teams get tripped up:
- Write throughput is unchanged. Every replica still depends on the same single primary for writes - you haven't touched the actual bottleneck if your problem is write volume.
- Storage capacity is unchanged. Every replica holds a full copy of the entire dataset. If your data no longer fits on one machine, replicas don't help - they just multiply the problem.
- Consistency gets weaker, not stronger. You're trading a guarantee (always read the latest write) for capacity. That trade is often worth it - but it is a trade.
Sharding: Scaling How Much You Can Write and Store
Sharding takes a different approach entirely: instead of copying the whole dataset onto more machines, you split it – horizontally partitioning rows across multiple independent databases, each responsible for its own slice.
Figure 4 – Each shard is a self-contained database handling its own reads and writes for its own slice of data.
A shard key (often a hash of the user or tenant ID) determines which shard a given row lives on. Because each shard is an independent primary, write throughput and storage capacity now scale roughly linearly with the number of shards – something replicas fundamentally cannot do, since every replica still carries the entire dataset.
The Real Cost: Anything That Spans Shards
The trade-off is that Redis leaderboards and SQL joins alike get harder the moment the data they need lives on more than one machine.
Figure 5 – A single-machine query becomes a scatter-gather operation once the data is split across shards.
- Cross-shard joins disappear. A join across two tables that happen to live on different shards isn't a SQL feature anymore - it's application code doing the join by hand.
- Global uniqueness gets harder. An auto-incrementing primary key that's unique per-shard is not unique across shards - you need a different ID strategy (UUIDs, or a dedicated ID-generation service).
- Resharding is expensive. Picking a bad shard key, or outgrowing your shard count, means physically moving data between machines while the system stays live - one of the more delicate operations in distributed systems.
- Transactions rarely span shards. An operation that needs to atomically touch rows on two different shards either needs a distributed transaction protocol or a redesign to avoid needing one.
In Production, You Usually Get Both
These aren’t competing techniques – they’re two separate knobs, and large systems turn both. Shard for write throughput and storage; then, inside each shard, add read replicas for read throughput within that slice.
Figure 6 – Sharding distributes the write load; replicas distribute the read load within each shard.
This is precisely why the framing “read replicas vs. sharding” is a bit of a false choice in practice. The real question is almost never “which one,” it’s “which one first, and does the other one ever become necessary too.”
Side by Side
| Dimension | Read Replicas | Sharding |
|---|---|---|
| Solves | Read throughput | Write throughput + storage size |
| Data per node | Full copy of everything | Only its own slice |
| Write scaling | None - one primary still | Yes - scales with shard count |
| Query complexity | Unchanged from single DB | Cross-shard joins get hard |
| Consistency | Eventual (replication lag) | Strong within a shard only |
| Operational cost | Low to moderate | High - resharding, routing, IDs |
Reach for Read Replicas vs. Reach for Sharding
Reads far outnumber writes (e.g. 95% GET, 5% write)
- Reads far outnumber writes (e.g. 95% GET, 5% write)
- The dataset still fits comfortably on one machine
- You can tolerate a few milliseconds of replication lag
- You want failover candidates, not just more capacity
- Analytics/reporting queries are slowing down live traffic
Reach for Sharding
- Write throughput exceeds what one primary can handle
- The dataset itself no longer fits on one machine
- You need to isolate noisy tenants from each other
- You've already added replicas and writes are still the ceiling
- You can define a durable, well-distributed shard key
Figure 7 – A quick gut-check for which lever actually matches your bottleneck.
The Interview Question You Should Actually Prepare For
If an interviewer asks, “Your database is slow – do you add read replicas or shard it?” the strongest opening move is refusing to answer until you’ve identified the bottleneck.
A Stronger Answer
“It depends on what’s actually maxed out. If it’s read throughput on a dataset that still fits on one machine, read replicas are the cheaper, faster fix – they don’t change the schema or the write path. If writes themselves are the bottleneck, or the dataset no longer fits on a single machine, replicas won’t move that needle at all, because every replica still carries a full copy and still depends on the same single primary for writes. That’s when sharding earns its complexi
And if the follow-up is “What breaks when you shard?” – that’s your cue to talk about cross-shard joins, global uniqueness, and resharding, in that order.
The Big Picture
It helps to think of a single database less like one machine and more like one small restaurant. Read replicas are like printing extra copies of the menu so more people can look at it at once – the kitchen (writes) is unaffected, and everyone’s still reading the same dishes. Sharding is like opening a second restaurant across town with its own kitchen, its own staff, and its own supply chain – you’ve genuinely doubled capacity, but now a customer who wants a dish from both locations has to place two separate orders.
Neither technique is “better.” They answer different questions – and the first job of any scaling effort is figuring out which question you’re actually being asked.
Start by finding the bottleneck before reaching for either tool. If reads are the pressure, replicas are cheap and fast. If writes or raw data size are the pressure, no number of replicas will save you – sharding, with all its added complexity, is the only lever that actually moves.
Design Scalable Systems with Confidence
Learn database scaling, sharding, replication, and real-world System Design with CodeKerdos.