When a single database can no longer keep up — reads, writes, or storage — engineers reach for two techniques that look similar from a distance and behave nothing alike up close. Replication makes copies of the same data on multiple machines. Sharding splits the data itself, so different machines hold different rows. They solve different problems, scale different bottlenecks, and have completely different operational profiles. Most teams need replication long before they need sharding, and the ones who jump straight to sharding usually regret it.

The replication architecture you will encounter 90% of the time is leader-follower (also called primary-replica). One node is the leader; it accepts all writes. Followers receive a stream of changes from the leader — usually the WAL (write-ahead log) — and apply them in order. Reads can go to any node; writes must go to the leader. The leader-follower model is simple, well-understood, and supported natively by every mainstream database.

Replication can be synchronous (the leader waits for follower acknowledgement before committing — safer, slower) or asynchronous (the leader commits immediately and replicates in the background — faster, risk of small data loss on failover). Most production systems use semi-sync: at least one follower must acknowledge, but not all. It buys most of the durability of sync without the latency hit.

When you need writes accepted in multiple regions or want to survive leader failures with zero downtime, multi-leader replication is the next step up. Multiple nodes accept writes; changes flow between them in both directions. The price is conflicts — what happens when two leaders simultaneously update the same row to different values? Resolution strategies vary: last-write-wins (simple, sometimes lossy), version vectors (correct, complex), application-level merge (CRDTs, custom logic). Multi-leader is rarely needed and rarely worth the operational complexity unless you have a specific multi-region write requirement.

The naive way to shard is modulo: shard = hash(key) % N. The problem appears the moment you add or remove a node: now N changes, every key's shard changes, and you have to move all your data. Consistent hashing solves this: the hash space is mapped onto a ring; each node owns a contiguous arc; only keys on the affected arc need to move when nodes are added or removed. Virtual nodes — each physical node owns many small arcs instead of one big one — smooth out the distribution and make rebalancing finer-grained.

The order of escalation matters more than any single decision. Replication is cheap to add, well-supported by every database, and solves the problems most teams actually have: “our reads are saturating the database” and “we need to survive a node failure.” Sharding is operationally heavy, application-invasive, and only solves problems that genuinely require horizontal write scaling. Add replication when you need it. Add sharding when you can prove no other option will work.

Replication lag is not a theoretical concern. On a healthy PostgreSQL replica it is usually 5–50 ms; under heavy write load it can hit hundreds of milliseconds; during long-running queries on the primary it can stretch to multiple seconds; on a partitioned network it can be unbounded. Every system using read replicas has to design for the gap between “committed on primary” and “visible on replica.”

The classic bug: a user creates a comment, the page refreshes and reads from a replica, and the comment isn't there yet. The standard fix is route-by-recency: track the timestamp (or LSN) of the last write per session; route reads to the primary if the latest replica position is behind that timestamp. Less precise alternatives: route reads from the same user to the primary for a fixed window after any write (5–30 seconds covers ~99% of real lag).

A query that touches a single shard is fast. A query that has to consult every shard, gather partial results, and merge them in the application is slow, complex, and breaks the linear-scaling promise. SELECT COUNT(*) FROM orders across 50 shards means 50 queries, 50 result rows, and one application-level sum. JOINs across shards are worse: either denormalize so the joined data lives on the same shard, or accept that some queries cannot run efficiently in your sharded system.

The teams who run sharded systems happily share a few discipline patterns. They picked a shard key that appears in the WHERE clause of nearly every query — usually a tenant ID, user ID, or geographic region. They over-provisioned logical shards (often 256 or 1024) on day one so adding capacity is rebalancing, not resharding. And they treat the shard map as a critical artifact: stored, versioned, monitored, and routed through a single service so the application doesn't hard-code shard locations.