Synchronous replication is a database replication mode in which a transaction is acknowledged to the client only after at least one replica has confirmed that it received, stored or applied the change. Because the primary waits for that confirmation, a committed transaction survives the loss of the primary, giving a recovery point objective (RPO) of zero for failures the replicas do not share.
In databases, the guarantee has a direct cost: every commit includes at least one network round trip to a replica, and the primary can stall if replicas become unreachable. Synchronous replication is therefore a deliberate trade of write latency and availability for durability, and its configuration decides exactly which failures it protects against.
How synchronous replication commits a transaction
Most relational systems implement synchronous replication on top of their write-ahead log or transaction log. The commit sequence follows a fixed pattern in which the client waits for remote evidence of durability.
- The client issues
COMMITand the primary writes the commit record to its local log. - The log records are streamed to the synchronous replicas.
- Each replica writes, flushes or applies the records and sends an acknowledgment.
- When the required number of acknowledgments arrives, the primary reports success to the client.
The point at which a replica acknowledges determines the strength of the guarantee. PostgreSQL makes this explicit through the synchronous_commit setting, and other systems offer comparable levels under different names.
| Setting | Replica acknowledges after | Protection |
|---|---|---|
| remote_write | Data handed to the replica operating system | Survives primary crash, not replica OS crash |
| on | Data flushed to replica disk | Survives loss of primary and replica crash |
| remote_apply | Data replayed and visible on replica | Also gives read-your-writes on the replica |
| local | Primary flush only, no replica wait | No synchronous protection |
Synchronous, semi-synchronous and asynchronous modes
Replication modes form a spectrum from maximum durability to minimum latency. Understanding where synchronous replication sits helps match it to business requirements.
| Mode | Commit waits for | Data loss on primary failure | Write latency impact |
|---|---|---|---|
| Synchronous | Durable confirmation from replicas | None for confirmed commits | Highest, at least one round trip |
| Semi-synchronous replication | Receipt by a replica, often before flush | Very small window | Moderate |
| Asynchronous replication | Local commit only | Up to the current replication lag | None |
| Consensus-based (Raft, Paxos) | A majority quorum of nodes | None while a majority survives | One round trip to the quorum |
MySQL semi-synchronous replication waits only for a replica to receive the events and, when the timeout expires, silently falls back to asynchronous mode. That fallback is the essential difference: true synchronous replication either waits or refuses to commit, while semi-synchronous replication prefers availability once the timeout is reached.
Latency, distance and quorum configuration
The commit latency floor equals the round-trip time to the slowest required replica plus its flush time. Within one data center the round trip is typically well under 1 ms; between availability zones it is often 1 to 2 ms; across continents it can exceed 100 ms, which makes synchronous replication over long distances impractical for busy write workloads.
Modern systems avoid a single point of stalling with quorum commit. In PostgreSQL, synchronous_standby_names can require acknowledgments from the FIRST 1 of a priority list or from ANY 2 of three standbys. A quorum lets the primary continue when one replica is slow or down while still guaranteeing that every confirmed commit exists on the required number of nodes.
| Topology | Tolerates | Trade-off |
|---|---|---|
| One primary, one sync standby | Loss of either node without data loss | Primary blocks if the standby fails |
| Primary with ANY 1 of 2 standbys | One unavailable standby | Extra node and network cost |
| Three-node consensus cluster | Loss of any one node | Majority required for writes |
| Sync in region, async to remote site | Node loss locally, disaster remotely | Remote site may lag |
Implementations across database systems
The concept appears in nearly every enterprise database, with different terminology and failure semantics.
- PostgreSQL streaming replication with
synchronous_standby_namesandsynchronous_commit. - SQL Server Always On availability groups in synchronous-commit mode.
- Oracle Data Guard in Maximum Protection or Maximum Availability mode.
- MySQL Group Replication and Galera Cluster, which certify transactions across members before commit.
- Distributed SQL databases that replicate each data range through Raft groups.
Group Replication and Galera are often described as virtually synchronous: every node receives and certifies a transaction before commit, but other nodes may apply it slightly later. Reads on those nodes can still return slightly stale data unless consistency settings demand otherwise.
Failure modes and operational pitfalls
The most common surprise is that synchronous replication reduces availability when it is configured with a single required replica. If that replica fails or the network partitions, every write on the primary waits indefinitely, which looks like a full outage to applications.
| Pitfall | Consequence | Remedy |
|---|---|---|
| Single required standby | Writes hang when it fails | Quorum of two or more candidates |
| Automatic downgrade to async | Silent loss of the zero-RPO guarantee | Alert on mode changes |
| Failover to a non-synchronous replica | Loss of confirmed transactions | Promote only synchronized nodes |
| Ignoring split-brain risk | Two primaries accept writes | Fencing and quorum-based failover |
| Assuming replicas are readable at once | Stale reads after commit | Use remote_apply or read from primary |
Synchronous replication also does not protect against logical errors. A mistaken DELETE is replicated just as faithfully as a correct insert, so backups, point-in-time recovery or a delayed replica remain necessary.
The short version
Synchronous replication means the database does not say done until a copy is safe somewhere else. When you save something, the main server sends it to a second server and waits for that server to confirm it has stored it. Only then does your application get its confirmation.
It is like a bank teller who will not hand you a receipt until the branch office has recorded the deposit too. You wait a little longer, but if the first office burns down, your deposit is not lost. The risk is that if the branch office stops answering, the teller has to stop serving customers.
Where it makes a difference
A payment processor runs its transaction database on PostgreSQL in two availability zones of one cloud region, about 1.5 ms apart. It configures one primary and two standbys with synchronous_standby_names set to ANY 1 of the two and synchronous_commit set to on, plus an asynchronous replica in a distant region for disaster recovery.
When the primary’s zone loses power during a peak period, the cluster manager promotes the standby that holds every acknowledged commit. No confirmed payment is lost, and service resumes in under a minute. The added commit latency of about 2 ms per transaction is a price the business accepts, because losing confirmed payments would be far more costly.