Asynchronous replication is a method of copying data from one database or storage system to another where the primary system confirms a write operation is complete before the copy reaches the replica. The primary doesn’t wait for the replica to catch up. This makes writes faster but introduces a small delay, called replication lag, where the replica holds slightly older data than the primary.
How Asynchronous Replication Works
The process starts when a client writes data to the primary database. The primary commits that change locally and immediately tells the client “done,” without checking whether any replica has received the update. In the background, the primary packages up the change and sends it to one or more replicas, which apply it on their own schedule.
This is the key difference from synchronous replication, where the primary waits for at least one replica to confirm it has stored the data before acknowledging the write. In synchronous setups, every write requires a round trip to the replica and back. In asynchronous setups, the client never waits for that round trip, so writes complete faster.
The trade-off is straightforward: the replica is always slightly behind. If the primary crashes in that gap, any changes that hadn’t yet reached the replica are lost. That window is typically fractions of a second under normal conditions, but it can grow if the network slows down or the replica falls behind under heavy load.
Why It’s Faster Than Synchronous Replication
Synchronous replication adds coordination overhead to every single write. The primary must lock the transaction, send the data, wait for confirmation, and only then release the lock and respond to the client. That overhead directly reduces throughput and maximum capacity, because processing power is diverted away from handling new transactions.
Asynchronous replication avoids all of that. Without locking and round-trip coordination, more resources stay available for the primary’s core job: processing transactions. The result is higher throughput and lower write latency. For most high-performance consumer applications, the write latencies imposed by synchronous replication across geographically separated sites simply aren’t acceptable, making asynchronous replication the only practical option. In financial trading systems, for example, adding even 50 extra nanoseconds to processing time with synchronous replication can mean the difference between a profitable trade and a loss. Asynchronous replication lets these systems protect data without sacrificing speed.
Eventual Consistency
Because the replica lags behind the primary, asynchronous replication follows an eventual consistency model. If you write a value to the primary and immediately read from the replica, you might get the old value. Once the inconsistency window closes and no further updates are made, all reads will return the latest value. The system converges, just not instantly.
This creates a specific problem called “read-your-writes” inconsistency. Imagine you update your profile name, and the next page load pulls from a replica that hasn’t received the change yet. Your old name appears, even though the update succeeded. Some systems solve this on the client side by tracking version numbers: the client knows it last saw version 5, so it discards any read returning version 4 or earlier and retries until it gets current data.
Another challenge is conflict handling. When multiple replicas accept writes (in multi-primary setups), two users can update the same record at the same time on different nodes. Synchronous systems rarely face this because coordination prevents it. Asynchronous systems must resolve these conflicts after the fact, and the problem grows with write volume.
How Major Databases Handle It
Most popular relational databases default to asynchronous replication or treat it as their primary replication method.
MySQL includes asynchronous replication support in its base installation. Replication flows one direction, from the primary to the replica. All writes and updates go to the primary, while reads can be distributed across one or more replicas. Setting up a new replica involves copying a data dump from the primary, executing it on the new server, and configuring the replica to track the primary’s transaction log position.
PostgreSQL uses a primary-replica architecture where the primary handles all create, read, update, and delete operations, and replicas are read-only. Replication is asynchronous by default, and load balancing comes built in since the primary accepts writes while replicas handle reads. One notable limitation: replication doesn’t work between different PostgreSQL versions, so all servers in the architecture need to run the same version. Resynchronizing an outdated replica requires copying the entire database instance from the primary.
Microsoft SQL Server offers merge replication, which starts with a snapshot of the primary database copied to replicas. Unlike MySQL and PostgreSQL, merge replication allows data changes on both the primary and the replicas. The system tracks changes by automatically adding a unique identifier column to every replicated table, which gets populated during inserts and updates so that conflicts can be detected and resolved during synchronization.
Cross-Region Disaster Recovery
Asynchronous replication is the standard approach for disaster recovery across geographic regions. Cloud platforms like Azure use it to replicate data across regions so that if an entire data center goes down, a copy exists elsewhere. The reason it dominates long-distance replication comes down to physics: synchronous replication across hundreds or thousands of miles would force every write to wait for a signal to travel that distance and back, adding unacceptable latency.
With asynchronous cross-region replication, writes on the primary cluster’s shards don’t wait for the replicas in the remote region to confirm receipt. This keeps write performance in the primary region unaffected. The cost is a recovery point objective (RPO), the maximum amount of recent data you could lose in a disaster. Organizations typically design their asynchronous replication to keep the RPO under a defined threshold, often around five minutes.
Estimating the bandwidth needed to meet that target involves measuring how much data your primary system changes within the RPO window and ensuring your network link can transfer that volume in time. For a system with 56 GB of cached changes and a 5-minute RPO, for instance, you’d need roughly 1,920 megabits per second of replication bandwidth.
Monitoring Replication Lag
Replication lag is the single most important metric to watch in any asynchronous setup. It measures how far behind the replica is, usually in seconds or bytes. Under normal conditions, lag stays well under a second. Under heavy write loads or network congestion, it can climb to several seconds or more.
Each database engine exposes lag differently. MySQL and MariaDB provide a metric called “Seconds Behind Source” through a status command that estimates how far the replica trails the primary. PostgreSQL lets you calculate lag by comparing the current time against the timestamp of the last transaction the replica applied. MongoDB tracks lag for each secondary member in a replica set.
The two universal metrics across all engines are time lag (measured in seconds) and byte lag (measured in bytes of unprocessed replication data). A common alerting threshold is to trigger a warning when lag exceeds 5 seconds for more than 2 minutes. Sustained lag beyond that point means reads from replicas are returning increasingly stale data, and it could signal that the replica is struggling to keep up with the primary’s write rate. If the gap keeps widening, you’re heading toward a situation where the replica may need a full resync rather than catching up incrementally.