Synchronous vs Asynchronous Database Replication

Synchronous replication waits for a follower node to confirm it has durably received a write before the primary reports the transaction as committed; asynchronous replication commits on the primary and streams the change to followers afterward, without waiting. Every replicated database has to choose — or let you configure — one of these, and the choice is really a tradeoff between how safe a committed write is and how much latency every write pays for that safety. See what database replication is for the broader mechanics this article builds on.

What “commit” actually waits for

In a single-node database, a commit is simple: the write is durable once it’s on disk, and the client gets an acknowledgment. Replication adds a second question — durable where? A primary can hold multiple standby copies (replicas), and how those copies stay in sync determines what “committed” is allowed to mean.

Synchronous replication: the primary sends the write to one or more replicas and waits for at least one to acknowledge it has been received and persisted before telling the client the transaction succeeded. If the primary crashes the instant after commit, the write is guaranteed to exist on at least one other node — nothing is lost.

Asynchronous replication: the primary commits locally, acknowledges the client immediately, and ships the write to replicas in the background. Replicas lag behind by some amount of “replication lag” — milliseconds under normal load, longer under contention or network issues. If the primary crashes before a replica catches up, whatever hadn’t yet replicated is gone.

The latency and durability tradeoff

This is the core tension, and it shows up directly in write latency:

• Synchronous adds at least one network round trip to every write — client to primary to replica and back — before the client gets an acknowledgment. Write latency now includes the slowest replica you’re waiting on, which is why synchronous setups are usually deployed with replicas close together (same availability zone or region) rather than across the globe.
• Asynchronous returns as soon as the local write is durable, so write latency is close to what a single-node database would give you. The cost is deferred, not eliminated: a crash at the wrong moment turns into data loss, and read replicas can serve slightly stale data — a form of eventual consistency rather than strict consistency.

Neither option is “wrong” — they’re calibrated to different failure tolerances. A financial ledger where losing a committed transaction is unacceptable leans synchronous even at a latency cost. An analytics read replica or a cache-warming follower, where staleness by a few seconds is fine, has no reason to pay that cost.

Semi-synchronous replication

Many production systems land on a middle ground: semi-synchronous replication, where the primary waits for acknowledgment from at least one replica (not all of them) before committing, while additional replicas stay fully asynchronous. This bounds worst-case data loss — you’re guaranteed the write exists somewhere else — without paying the latency cost of waiting on every replica, including ones in distant regions. It’s the default or a supported mode in most major relational databases, precisely because pure synchronous replication to a full replica set is rarely worth its tail latency in practice.

Failover behavior differs sharply

The replication mode also determines what happens during a failover, which is why the choice connects directly to your RPO and RTO targets:

	Synchronous	Asynchronous
Write latency	Higher — waits on replica ack	Lower — local commit only
Data loss on primary failure	None (from acknowledged writes)	Possible — unreplicated writes are lost
Best deployment topology	Same region / low-latency link	Any distance, including cross-region
Typical use	Financial systems, primary-critical data	Read replicas, cross-region DR, analytics
Failover complexity	Simpler — replica is guaranteed current	Requires reconciling in-flight lag

With synchronous replication, promoting a replica to primary during failover is straightforward: the replica you waited on is known to be caught up. With asynchronous replication, the replica being promoted might be missing the last few committed writes, so failover procedures need to account for that gap — either by accepting the loss, or by holding writes until confirmed lag reaches zero, which itself reintroduces a synchronous-style wait at exactly the moment you can least afford it.

How this interacts with active-active setups

The synchronous/asynchronous choice is orthogonal to but closely related to the active-active vs. active-passive decision. An active-passive pair typically uses synchronous or semi-synchronous replication to the standby specifically so failover is safe. Active-active topologies, where multiple nodes accept writes simultaneously, almost always use asynchronous replication between nodes plus a conflict-resolution strategy, because synchronously coordinating every write across multiple write-accepting nodes would collapse write throughput to whatever the slowest node in the group can sustain.

Choosing one in practice

A few questions settle most of the decision:

• Can you tolerate losing the last few committed writes on an unclean primary failure? If no, synchronous (or semi-synchronous) is close to mandatory.
• How far apart are your replicas? Cross-region replicas make full synchronous replication a serious latency tax; asynchronous or semi-synchronous is the norm there.
• What’s actually replicating — the primary’s only standby, or a fleet of read replicas? Waiting synchronously on every read replica is rarely worth it; semi-synchronous to one nearby replica, async to the rest, is a common pattern.
• What does your database’s isolation and consistency model already promise? Replication mode should be consistent with the guarantees the rest of the system is making, not an afterthought bolted on separately.

The takeaway

Synchronous replication makes a commit mean “durable on more than one node,” at the cost of every write waiting on a network round trip to a replica. Asynchronous replication makes a commit fast and local, at the cost of a window where an unreplicated write can be lost if the primary fails. Semi-synchronous replication is the practical middle ground most systems actually run: guaranteed durability to at least one replica, without waiting on all of them. Pick based on how much data loss you can tolerate on failover and how far apart your replicas physically are — not by default.