Database scaling

Caches, replicas and shards against reads, writes and load.

On the roadmap:Beginner · step 6: Scaling one server

Starterabout 10 to 15 min5 experiments

Experiments

New here? A few short steps show what happens, one at a time.

Start from a situation

Workload

Requests per second20,000

Share of reads90%

Scaling levers

Cache hit rate0%

Read replicas per shard0

Shards (write scaling)1

Busiest machine

240%

Typical latency

timeouts

Database machines

Reach the database

20,000/s

Overloaded: requests queue up and time out. Read heavy: raise the cache hit rate (bigger or smarter cache) before adding hardware. Add read replicas to spread the read load.

Your database tier, machine by machine

Shard 1

Primary

240%

Green is comfortable (under 70%), amber is getting tight, red is saturated: requests queue and time out.

Node utilisation (100% = saturated)

240

Primary

Replica

What reaches the database

20,000 req/s

18,000 reads · 2,000 writes

Typical latency: timeouts

An illustrative model (a read costs 1 unit, a write 3, one node handles 10,000 units a second), designed to show relative effects, not to predict your production numbers.

In plain words

A database can only do so many operations a second. A cache takes reads away from it, replicas share the reads between more machines, and shards split the writes over more primaries. This simulator shows which lever helps your kind of traffic.

Why it matters

Adding hardware without knowing the bottleneck wastes money. Replicas do nothing for a write-bound database, and a cache does nothing for traffic with no repeated reads. The model is simple, but the habit is how real capacity planning starts: find the busiest machine, then pick the lever that lowers its load.

How real systems do it

The simulation is a simplified model. Here is what production systems add or do.

Read replicas, caching and sharding are the usual levers, in roughly that order, because each is more work to run than the one before.
Replicas share reads, but every replica still applies every write, so write-heavy loads need sharding.
Latency climbs sharply as a machine nears its limit, which is why teams plan to stay well below 100% busy. This model treats 70% as the comfortable ceiling.
Real capacity planning is driven by load tests and the busiest machine's metrics, not by a model like this one.