Asynchronous replication acknowledges a commit as soon as the primary has it durably. The replica receives the change shortly after. If the primary fails in that window, those writes are lost — the replica is promoted without them.
Synchronous replication closes that window by waiting for a replica to confirm before acknowledging the commit. Nothing is acknowledged that is not on at least two machines.
What changed in 2026
- Quorum-based configuration became standard. Requiring a majority of several replicas rather than one specific replica removed the single-point dependency.
- Managed platforms offered it as a toggle. Selecting the durability level became a configuration choice rather than an infrastructure project.
- Cross-region cost stayed prohibitive for most. The latency of synchronous cross-region commits kept it a specialist choice.
- Mixed configurations spread. Synchronous locally, asynchronous to a distant region, became a common shape.
What you gain and pay
|
Asynchronous |
Synchronous |
| Commit latency |
Primary only |
Primary plus replica round trip |
| Data loss on failover |
Recent writes |
None acknowledged |
| Replica failure impact |
None on writes |
Can block writes |
| Cross-region viability |
Good |
Expensive |
| Throughput |
Higher |
Lower |
The gain is precise: no acknowledged write is lost on failover. If your system told a user something succeeded, it survives the primary failing.
The cost is equally precise: a network round trip on every commit. On a local network that is small; across regions it is tens of milliseconds, on every write, forever.
The availability trap
Naive synchronous replication creates a dependency people do not anticipate: if the replica is down or slow, commits block.
You configured replication for durability and got a system where a replica failure causes a write outage — a worse availability posture than before.
The fix is quorum-based configuration: require confirmation from any one of several replicas, or from a majority, rather than from one named replica. Then a single replica failing does not block anything, because another can acknowledge.
That requires at least three replicas to be meaningful. With one synchronous replica, its failure is your outage.
Some systems also degrade automatically, falling back to asynchronous when no replica can confirm. That preserves availability and silently gives up the guarantee — which may be right, and should be a deliberate choice rather than a surprise discovered after an incident.
Where it belongs
Synchronous replication is a durability decision, and durability requirements vary by data.
Worth it: financial transactions, order placement, anything where losing an acknowledged write means a customer was told something untrue about money or commitment.
Usually not: analytics events, logs, cached derivations, session data, and anything reconstructable from another source.
Many systems apply it selectively — synchronous for the transactional core, asynchronous for everything else. That gets the guarantee where it matters without paying latency on every write in the system.
Geographic placement is the other lever. Synchronous replication within a region or availability zone is cheap enough to be routine; extending it across continents is not. A common shape is synchronous locally for zero-loss failover within a region, plus asynchronous to a distant region for disaster recovery with an accepted loss window — see point-in-time recovery for what that window means in practice.
Common mistakes
- One synchronous replica. Its failure blocks writes.
- Cross-region synchronous by default. Latency on every commit.
- Applying it to all data uniformly. Paying for a guarantee most data does not need.
- Not knowing whether automatic degradation is enabled. You may not have the guarantee you think.
- Ignoring the throughput effect. Longer commits mean fewer per second.
- Assuming it protects against everything. It addresses failover loss, not corruption or accidental deletion.
- No monitoring of replica confirmation latency. Slow confirmation degrades every write.
FAQ
How much latency does it add?
Roughly the network round trip to the replica plus its durable write. Small within a datacentre, substantial across regions. Measure on your topology.
Does it protect against accidental deletion?
No — a deletion replicates faithfully. That is what backups and point-in-time recovery are for.
Can I have both?
Yes, and it is common: synchronous to a nearby replica for zero-loss failover, asynchronous to a remote one for disaster recovery.
What if all synchronous replicas are unavailable?
Depending on configuration, writes block or the system degrades to asynchronous. Knowing which your system does, before it happens, matters.
Where to go next
For the asynchronous default and its lag, read replication lag. For recovery beyond failover, point-in-time recovery, and for the consensus-based approach, Raft consensus.