At scale

What changes once one machine isn't enough.

Replication

Copies the same data onto more than one machine, so you have a backup ready to take over and somewhere to send read traffic.

Think: keeping identical spare keys cut for the same lock.

Sharding

Splits the data itself across machines, so each one only holds a slice and no single disk has to hold it all.

Think: cutting one big key into pieces, each useless alone.

Replication: copies for safety and speed

A replica is a second copy of your database that stays in sync with the original, usually by streaming the same write-ahead log used for crash recovery. Two reasons to bother:

• Failover, if the primary machine dies, a replica can be promoted to take over in seconds instead of you restoring last night’s backup.

• Read scaling, send read-only queries to replicas so the primary machine is free to focus on handling writes.

The catch: replicas usually lag the primary by a small amount, from milliseconds to seconds. Read from a replica right after a write and you might not see your own change yet, a subtle bug that tends to show up as “I just saved this and it’s gone” support tickets.

Sharding: when one machine isn’t enough, period

Replication copies the same data everywhere. Sharding does the opposite, it splits the data itself across machines, so each one only holds a slice. Customer IDs 1 through 1,000,000 might live on shard A, the rest on shard B. This is what lets a system hold more data than any single disk could, and take more write traffic than any single machine could process.

The cost is real: a query that needs data from two shards at once, “show me all orders across every customer”, now has to ask multiple machines and stitch the results together, and cross-shard transactions range from awkward to effectively impossible. Most teams should exhaust vertical scaling (a bigger machine) and read replicas before reaching for sharding, it solves a real problem, but it’s rarely the first problem worth solving.

Dimension	Replication	Sharding
What moves	The same data, copied to more machines	Different slices of data, split across machines
Solves	Failover and read scaling	Total data size and write throughput
Main risk	Replication lag, stale reads	Cross-shard queries and transactions get hard
Reach for it	First, almost always	Last, once replicas and a bigger machine aren't enough

Tip

Scale in this order: get a bigger machine, then add read replicas, then consider sharding. Each step is more work and more operational risk than the one before it, so skip ahead only once you have actually outgrown the simpler option.