What Is Database Replication? Copies, Consistency, Failover

Database replication is the practice of maintaining copies of the same data on multiple servers, kept in sync as writes happen, so a system can survive the failure of any single database instance and spread read traffic across more than one machine. It’s one of the primary tools for making a database both more available and more scalable, at the cost of some added complexity around how quickly — and how reliably — those copies stay in sync.

Why replicate at all

A single database server is a single point of failure: if the disk fails, the process crashes, or the underlying host goes down, every application depending on it goes down too. Replication addresses this by keeping a live, continuously updated copy on a separate server, ready to take over if the primary fails.

It also addresses a scaling problem that’s separate from availability. Most applications read data far more often than they write it. If every read has to go to the same server as every write, that server becomes a bottleneck long before the underlying hardware is actually full. Replication lets read traffic spread across multiple copies while writes still go to one place, which is often enough headroom to avoid more invasive scaling work like sharding.

Primary-replica replication

The most common pattern is primary-replica (sometimes called leader-follower): one server, the primary, accepts all writes. It streams a log of those changes to one or more replica servers, which apply the same changes and stay a close copy of the primary’s state. Read queries can be directed to any replica, spreading load; write queries must go to the primary, since replicas aren’t allowed to accept writes that could conflict with the primary’s own stream of changes.

If the primary fails, one replica is promoted to become the new primary — either automatically by the database’s own failover tooling, or manually by an operator, depending on how the system is configured. This is the core mechanism behind most managed database “high availability” offerings.

Synchronous vs asynchronous replication

The critical design choice in any replication setup is how a write is acknowledged relative to when replicas actually receive it:

• Synchronous replication — the primary waits for at least one replica to confirm it has received and applied the write before telling the client the write succeeded. This guarantees no data loss if the primary fails immediately after, but adds latency to every write, since it now depends on a network round trip to another server.
• Asynchronous replication — the primary acknowledges the write immediately and streams it to replicas in the background. Writes are fast, but there’s a window where the primary has data the replicas don’t yet have. If the primary fails during that window, that data can be lost when a replica is promoted.

Many production systems use a middle ground: synchronous replication to one nearby replica for durability, and asynchronous replication to additional replicas further away for read scaling, without paying the full latency cost of waiting on every copy.

Replication lag

Because asynchronous replicas apply changes with a delay, a read from a replica can return data that’s slightly out of date relative to the primary — this gap is called replication lag. It’s usually small under normal load, but can grow under heavy write traffic or network issues. Applications that read their own writes immediately after making them — showing a user their own just-submitted comment, for instance — need to either read from the primary for that specific query or account for the possibility that a replica hasn’t caught up yet.

This is the same underlying tension that shows up across distributed systems more broadly: strict consistency and horizontal scalability pull in opposite directions, and replication lag is where that tradeoff becomes concrete and measurable rather than abstract.

Replication vs backups

These are sometimes conflated because both involve extra copies of data, but they protect against different failure modes. A backup is a point-in-time snapshot, usually stored separately and restored manually, that protects against data corruption, accidental deletion, or a bug that writes bad data — you can roll back to a backup from before the mistake happened. Replication is a live, continuously updated copy that protects against hardware or availability failure — but a replica faithfully copies a bad write or a deletion just as quickly as a good one, so replication alone doesn’t protect against human or application error the way a backup does. A resilient system needs both.

	Replication	Backups
Protects against	Server/hardware failure	Data corruption, accidental deletion
Data freshness	Near real-time	Point-in-time snapshot
Recovery speed	Fast (failover)	Slower (restore process)

The takeaway

Database replication keeps synchronized copies of data across multiple servers, giving a system both failover protection and the ability to spread read traffic across replicas — with the synchronous-vs-asynchronous choice determining how much latency you pay upfront versus how much data you risk losing if the primary fails. It solves availability and read scaling, not data-corruption protection, which is why a solid setup pairs replication with regular backups rather than treating either one as sufficient on its own — the same reasoning that shapes how systems like Redis and PostgreSQL each implement their own replication features.