Why We Split the Database

In the last explainer you learned to scale the app by running many forgetful servers behind a load balancer. So you did. You have ten servers now. And the site is still slow under load.

Here's why. All ten servers talk to the same single database. You cloned the easy part (the stateless workers) and left the hard part (the one machine that remembers everything) exactly as it was. Now ten servers are all queuing up at one database's door.

The database is hard to scale precisely because it holds state. You can't just run ten copies and call it a day, because then you'd have ten different versions of the truth. So scaling a database is its own journey, with its own order of moves. Let's walk it.

First, see what's actually slow

Before splitting anything, look at the traffic. Almost every app does far more reading than writing. Loading a feed, opening a profile, searching products — all reads. Posting, liking, buying — writes, and there are way fewer of them.

That imbalance is a gift, because reads are easy to copy and writes are not. It tells you where to push first.

Move one: add read replicas

You keep your main database (call it the primary) as the one place writes go. Then you add one or more copies of it, called read replicas. The primary continuously streams its changes to the replicas so they stay nearly up to date. Reads get spread across the replicas; writes still all go to the primary.

Since reads are 90% of your traffic, spreading them across three replicas roughly cuts the busiest database's load to a fraction of what it was. For a read-heavy app this one move buys an enormous amount of headroom, and it needs no change to how your data is shaped.

But — and you can probably feel the pattern by now — it introduces a new problem.

The new problem: replication lag

Copying changes from the primary to the replicas isn't instant. It usually takes milliseconds, but under load it can stretch to seconds. In that gap, a replica is showing slightly old data. This delay is replication lag, and it produces a very specific, confusing bug.

The common fix is targeted: for the brief window right after a user writes something, read their data from the primary instead of a replica, so they always see their own latest change. Everyone else can keep reading from replicas, where being a second behind doesn't matter. You're not demanding the whole system be instantly consistent, just the one spot where staleness is visibly wrong.

Before you shard: exhaust the cheaper moves

Replicas solved reads. But every write still goes to the single primary, and replicas don't help with that — they're copies, not extra write capacity. So the obvious next thought is "split the writes too." Resist it for as long as you can, because there's a lot of road left before you have to.

A bigger machine is the first answer, and it's not a joke answer. Modern hardware is enormous; a single well-tuned primary handles a write rate that would have needed a cluster a decade ago. Before that, fix what's actually slow: add the missing index, kill the query that scans the whole table, batch chatty writes, move rarely-changing computed data into a cache. Most "we need to shard" moments are really "we have one unindexed query" moments.

There's also a middle step between replicas and full sharding: functional partitioning (sometimes called federation). Instead of slicing one table across machines, you move whole tables to their own database — billing on one box, the product catalog on another, the activity log on a third. Each piece gets its own primary and its own write capacity, and you've gained a lot without the pain that comes from splitting a single table. The limit is that one table can still outgrow one machine, and a feature can't be moved to its own database if it's tangled into everything else.

When one primary still can't cope

Eventually, on a genuinely large system, two things force the harder move even after you've done all of the above:

1. Too many writes. One table takes writes faster than any single machine can commit them.
2. Too much data. A single table grows past what one machine can store or index efficiently, and queries slow down from sheer size.

You've already met the answer to "one machine isn't enough" — use more machines. But you can't just clone the primary, because writes would conflict. Instead you split the data itself across several databases, so each one holds a slice and handles the writes for that slice. This splitting is called sharding, and each slice is a shard.

How sharding works

You pick a shard key — a field you'll use to decide which database a row lives in. User ID is a common one. Then a rule sends each row to a shard based on that key.

Now users 0–49 live on shard A, 50–99 on shard B, and so on. Each shard is a smaller, faster database handling only its slice of users and their writes. Add a fourth shard and you've added write capacity and storage. This is horizontal scaling again, applied to data instead of compute.

It works, and it's how the largest systems store their data. But sharding is the most expensive move in this whole sequence, and you should respect why.

The order, and the discipline

The whole journey, in the order the pain forces it:

1. Ten servers, one database, still slow

   The servers were the easy part. The shared database is the real bottleneck.

2. Reads are most of the load

   Add read replicas and spread reads across them. The primary handles writes. Huge, cheap win for a read-heavy app.

3. Users don't see their own just-saved changes

   That's replication lag. Route a user's own reads to the primary right after they write; let everyone else read from replicas.

4. Writes outgrow the primary, after the cheap fixes run out

   First a bigger machine, the missing index, functional partitioning by feature. Only when those are spent do you shard: split one table across databases by a shard key, each handling a slice. Powerful, and the costliest step — cross-shard queries and transactions get hard.

The discipline is the same as everywhere else in backend work: stop at the first move that solves your problem. A great many successful apps never shard at all, because one primary with a few read replicas carries them for years. Sharding is the move you make when you've earned the scale that demands it — not a day sooner.