Synchronous and asynchronous database replication differ in when data is copied to replica nodes: synchronous replication commits a transaction only after all replicas confirm it, while asynchronous replication commits first and propagates changes later. Choose synchronous when data loss of even one transaction is unacceptable and your network is fast and reliable; choose asynchronous when availability, write throughput, or geographic distribution matter more than absolute consistency.
What Replication Actually Does
Replication is the process of maintaining copies of a database on multiple servers. The primary (or master) node accepts writes, and replica (or slave) nodes receive those changes so they can serve reads or act as failover targets. The replication method determines when a write is acknowledged to the client and how current each replica is at any moment.
Both methods use the same underlying mechanisms—write-ahead logs, binary logs, or change streams—but the critical difference is the acknowledgment protocol. In synchronous replication, the primary waits for a replica to confirm it has persisted the change before telling the client the transaction succeeded. In asynchronous replication, the primary responds immediately and ships the change to replicas in the background.
How Synchronous Replication Works
In a synchronous setup, the transaction lifecycle includes a coordination step. The primary executes the transaction, writes it to its local log, then sends the commit record to all synchronous replicas. Each replica applies the change and sends back an acknowledgment. Only after all required acknowledgments arrive does the primary send a success response to the client.
This guarantees that if the primary fails immediately after acknowledging a write, every synchronous replica has that write. No committed transaction is lost. However, the added round trips increase latency—every write waits for the slowest replica. If a replica becomes unreachable, the primary typically blocks writes until it recovers or a human intervenes, because it cannot safely acknowledge without the replica’s confirmation.
Common implementations include:
- PostgreSQL synchronous_commit with
remote_apply(waits for replica to apply) oron(waits for replica to write to WAL). - MySQL semi-synchronous replication, which requires at least one replica to acknowledge.
- MongoDB’s majority write concern, which waits for a majority of voting nodes.
How Asynchronous Replication Works
Asynchronous replication is simpler: the primary commits locally, sends the change to replicas via a log stream, and does not wait for any acknowledgment. The client gets a success response as soon as the primary has persisted the write. Replicas apply changes at their own pace, which introduces a replication lag—a delay between when a write happens on the primary and when it appears on a replica.
This design gives two major benefits: low write latency (no extra network round trips) and high availability (the primary can keep accepting writes even if replicas are offline). The trade-off is that if the primary fails before replicas catch up, the latest writes are lost. Also, reads from replicas may return stale data, so applications must handle eventual consistency.
Examples include:
- MySQL default asynchronous replication.
- PostgreSQL streaming replication with
synchronous_commit = off. - Cassandra’s default replication, which is asynchronous per node (though it uses quorum reads/writes for consistency).
Key Differences at a Glance
To make the choice concrete, compare the core trade-offs:
- Data safety: Synchronous guarantees zero committed-transaction loss; asynchronous can lose the last few seconds of writes.
- Write latency: Synchronous adds the replica’s round-trip time; asynchronous adds nearly nothing.
- Availability: Synchronous can block writes if a replica is down; asynchronous keeps accepting writes.
- Read consistency: Synchronous replicas are always current; asynchronous replicas may lag.
- Network requirements: Synchronous needs low, stable latency; asynchronous tolerates high latency and intermittent connectivity.
- Scalability: Asynchronous scales to many replicas more easily; synchronous degrades with distance and replica count.
How to Choose: Decision Factors
There is no universal best option—the right choice depends on your workload and business requirements. Walk through these questions in order:
- What is the cost of losing a committed transaction? Financial systems, order processing, and inventory updates usually require synchronous. Analytics, logs, and caches can tolerate loss.
- What is your maximum acceptable write latency? If your application needs sub-10ms writes, synchronous replication across a WAN may be impossible. Keep replicas in the same data center or use asynchronous.
- How far apart are your nodes? Synchronous replication over distances >10ms round-trip is impractical. Use asynchronous for disaster recovery across regions.
- What happens when a replica fails? Can you afford to pause writes while the replica is repaired? If not, choose asynchronous or a semi-synchronous compromise.
- Do reads need to be immediately consistent? If users see their own writes right away, synchronous replicas or read-from-primary are needed. Asynchronous is fine for eventual consistency.
A common middle ground is semi-synchronous replication: the primary waits for at least one replica to acknowledge, but not all. This limits data loss to a single node failure while keeping latency lower than full synchronous. MySQL’s semi-synchronous mode and PostgreSQL’s quorum commit are examples.
Common Problems and Misconceptions
A frequent misconception is that synchronous replication makes a system fully consistent. It does not—it only ensures that committed writes exist on the primary and the required replicas. Reads can still return different results if your application reads from a replica that hasn’t applied a write yet (though in synchronous, that window is tiny). Also, synchronous replication does not protect against all failure modes: if the primary and a replica both fail simultaneously, data can still be lost.
Another common issue is misconfiguring the number of synchronous replicas. If you require two replicas but only one is available, writes will block. Some systems allow a fallback to asynchronous after a timeout, but that creates a window of potential loss. Monitor replication lag and replica health carefully.
Network partitions are particularly nasty for synchronous replication. If the primary cannot reach a replica, it must choose between blocking writes (sacrificing availability) or proceeding without acknowledgment (sacrificing durability). This is the classic CAP theorem trade-off. Many production systems use a quorum-based approach (like MongoDB’s majority or Cassandra’s LOCAL_QUORUM) to avoid single-node blocking.
Costs and Operational Considerations
Synchronous replication is not free. The most obvious cost is latency: every write pays the round-trip to the replica. On a 1ms network, that adds 2ms per write; on a 100ms WAN link, it adds 200ms. This can reduce write throughput dramatically, especially for write-heavy workloads.
There is also an availability cost. If a synchronous replica fails, the primary may stop accepting writes until the replica is restored or you reconfigure the replication set. This requires careful monitoring and automated failover procedures. Asynchronous replication has lower operational overhead but requires you to handle replication lag and potential data loss during failover.
Hardware costs are similar—both require the same storage and compute for replicas. The real cost difference is in engineering time: designing for synchronous replication requires more careful capacity planning and failure testing.
Alternatives and Hybrid Approaches
If neither pure synchronous nor pure asynchronous fits, consider these alternatives:
- Semi-synchronous: Wait for one replica, not all. Balances durability and latency.
- Quorum-based: Require a majority of nodes to acknowledge (e.g., MongoDB majority, Cassandra QUORUM). Good for distributed systems.
- Group replication: MySQL Group Replication uses a consensus protocol to replicate to a group of nodes, providing strong consistency with automatic failover.
- Change data capture (CDC): Stream changes to a message queue (Kafka) and apply asynchronously. Useful for event-driven architectures, but still asynchronous.
- Read-your-writes consistency: Route reads for a user to the primary until a short time passes, then allow replicas. This masks lag for the most common case.
Frequently Asked Questions
Can I switch from asynchronous to synchronous without downtime?
Yes, most databases allow you to change the replication mode dynamically. In PostgreSQL, you can set synchronous_commit per-session or globally. In MySQL, you can enable semi-synchronous replication at runtime. However, you must ensure all replicas are caught up before enabling synchronous mode, otherwise the primary will block waiting for a lagging replica. Plan the switch during a low-write period and monitor lag closely.
Does synchronous replication prevent all data loss?
No. It prevents loss of committed transactions when the primary fails and at least one synchronous replica survives. But if the primary and all synchronous replicas fail simultaneously (e.g., a data center power outage), you can still lose data. Also, transactions that were in progress but not committed are lost by design. For absolute durability, you need backups and possibly multi-datacenter synchronous replication.
Is asynchronous replication ever safe for financial data?
Generally, no. Financial systems require that a committed transaction never be lost. Asynchronous replication can lose the last few seconds of writes if the primary fails. Some systems use asynchronous replication for reporting replicas but keep the primary durable with synchronous replicas in the same data center. If you must use asynchronous, you need a robust failover process that accepts the risk of losing recent transactions, which is rarely acceptable for finance.
What is replication lag and why does it matter?
Replication lag is the delay between a write on the primary and its application on a replica. It is measured in seconds or bytes behind. High lag means replicas serve stale data, and failover may lose more writes. Monitor lag continuously; if it grows, your replicas are undersized or the network is saturated. Some systems let you set a maximum lag threshold and route reads away from lagging replicas.
Which is better for a multi-region setup?
Asynchronous replication is almost always used across regions because synchronous replication over intercontinental links adds hundreds of milliseconds of latency, making writes unusably slow. For multi-region, use asynchronous replication for disaster recovery and accept a recovery point objective (RPO) of seconds to minutes. If you need stronger consistency across regions, consider a globally distributed database like Spanner, but that is a different architecture entirely.