Asynchronous replication is a database replication mode in which the primary confirms a transaction to the client first and sends the change to replicas afterwards, without waiting for any replica to receive or apply it. In database replication, it is the most common default because it keeps write latency independent of replica distance and health.
The price of that speed is a window of exposure. Replicas always trail the primary by some replication lag, and if the primary fails before recent changes have been shipped, those committed transactions can be lost during failover. Asynchronous replication is therefore a deliberate trade-off between performance and availability on one side and durability guarantees on the other, and it is the standard mode for read replicas, reporting copies and geo-replication across regions.
How asynchronous replication works
The primary writes every change to its transaction log, such as the binary log in MySQL or the write-ahead log (WAL) in PostgreSQL, and commits locally. A separate process then streams the log records to replicas, which store and replay them to reproduce the same data.
- The client sends a transaction to the primary.
- The primary writes the change to its log, commits and acknowledges the client.
- Log records are sent to each replica over the network.
- Each replica writes the records locally and applies them in commit order.
Because the acknowledgment in step 2 does not depend on steps 3 and 4, a slow or disconnected replica does not slow the primary. The replica simply falls behind and catches up later from the retained log, as long as the primary still keeps the required log segments.
Replication lag and the data loss window
Replication lag is the delay between a commit on the primary and its visibility on a replica. On a healthy local network it is often milliseconds to a few seconds, while across regions, under heavy write load or during long-running transactions it can grow to minutes or more.
Lag has two components: transfer delay, the time to ship log records, and apply delay, the time the replica needs to replay them. A replica with a single apply thread can fall behind a primary that executes many transactions in parallel, which is why many systems support parallel apply on replicas.
| Source | Effect | Typical mitigation |
|---|---|---|
| Network latency and bandwidth | Slower log transfer | Compression, closer replicas, faster links |
| Large or long transactions | Replica applies big batches late | Smaller batches, chunked migrations |
| Single-threaded apply | Replica cannot keep pace with parallel writes | Parallel replication workers |
| Replica load | Heavy read queries compete with apply | Separate reporting replicas |
| Slow replica storage | Writes on the replica take longer | Storage matching the primary |
The amount of data that can be lost on failover, the recovery point objective (RPO), is roughly equal to the lag at the moment of failure. Asynchronous replication therefore offers an RPO greater than zero, which must be acceptable to the business.
Asynchronous, synchronous and semi-synchronous replication
Replication modes differ in when the primary acknowledges a commit. That single choice determines write latency, durability and how replica failures affect the primary.
| Mode | Commit acknowledged when | Data loss on primary failure |
|---|---|---|
| Asynchronous | Primary has committed locally | Possible, up to the current lag |
| Semi-synchronous | At least one replica has received the change | Usually none, unless fallback occurred |
| Synchronous | Required replicas have durably written or applied it | None for acknowledged transactions |
| Quorum-based (Raft, Paxos) | A majority of nodes has persisted it | None while a majority survives |
Synchronous modes add at least one network round trip per commit, which is negligible within a data center but significant across continents, where round trips often exceed 100 ms. Many deployments therefore combine modes: synchronous or semi-synchronous within a region and asynchronous to distant regions.
Where asynchronous replication fits
Asynchronous replication suits workloads where write performance and primary availability matter more than losing the last moments of data in a rare failure. The decision table shows typical situations.
| Situation | Recommendation | Reason |
|---|---|---|
| Scaling reads with read replicas | Asynchronous | Replica issues must not block writes |
| Disaster recovery in another region | Asynchronous | Distance makes synchronous commits too slow |
| Financial ledgers | Synchronous or quorum | Losing acknowledged transactions is unacceptable |
| Analytics and reporting copies | Asynchronous | Slightly stale data is acceptable |
| Delayed replica for error recovery | Asynchronous with apply delay | Lag is intentional protection |
Risks and operational pitfalls
Applications that read from asynchronous replicas must tolerate stale reads. A user who updates a profile and immediately reloads the page from a lagging replica may see the old value, so many systems route a user’s reads to the primary for a short time after a write, an approach called read-your-writes consistency.
- Monitor lag continuously and alert before it exceeds the agreed recovery point objective.
- Fence the old primary during failover so that it cannot accept writes and cause split-brain.
- Reconcile lost transactions after failover, because the old primary may contain commits the new one never received.
- Retain enough log on the primary so that a disconnected replica can catch up without a full resync.
- Do not treat a replica as a backup, since deletions and corruption replicate as well.
A non-technical view
Imagine a shop manager who records every sale in a main ledger and, every few seconds, sends copies of the new entries to a branch office. Customers do not wait for the copy to arrive; they get their receipt immediately. That is asynchronous replication: the main database confirms the work first and updates the copies a moment later.
It keeps everything fast, and the branch office can answer questions from its copy. The catch is that if the main office burns down just after a sale, the last few entries may never reach the branch. Speed is gained by accepting a small risk of losing the newest changes.
A concrete example
An online marketplace runs its main PostgreSQL database in one European region with two asynchronous streaming replicas: one in the same region that serves product searches, and one in a second region for disaster recovery. Typical lag is under 100 ms locally and about 1 second to the remote region.
One night, the primary region suffers a prolonged outage. The operations team promotes the remote replica to primary, accepting the agreed recovery point objective of 5 seconds. A comparison of the logs later shows that about 40 order updates committed in the final second were missing, and the team reprocesses them from the payment provider’s records.
Because writes never waited for the distant region, normal checkout latency stayed low for years, and the outage cost minutes of downtime instead of hours.