Replication Lag
Also known as: replica lag, replication delay
Replication lag is the delay between a write committing on the primary and becoming visible on a replica. It is normally milliseconds, but it grows with write volume, long-running queries on the replica and single-threaded apply, and every read served from a lagging replica returns stale data.
Last reviewed · Part of the Architecture Glossary
In practice
Measure the lag in bytes and seconds, not just seconds. A replica showing 0 seconds because it has nothing to apply is different from one that is genuinely caught up; pg_wal_lsn_diff and Seconds_Behind_Master tell you different halves of the story.
What makes it spike:
- A bulk write — a migration or backfill produces WAL faster than the replica applies it.
- Long-running read queries on the replica, which delay apply (Postgres
max_standby_streaming_delayis the knob, and it forces a choice between cancelling the query and letting lag grow). - Single-threaded apply. MySQL's classic replication applies serially; a write burst on the primary that used 16 cores applies on one.
- Network saturation between regions.
Handling it in the application: route read-your-writes traffic to the primary, expose lag to the router so it can drop a replica out of the pool past a threshold, and treat "replica is more than N seconds behind" as an alert rather than a dashboard curiosity.
When it matters
Any read-replica pool, any cross-region deployment, and any failover plan — promoting a replica that is 40 seconds behind loses 40 seconds of committed writes.
Common mistake
Failing over on the assumption that async replication is lossless. It is not, by construction. If the RPO is zero, the write path needs synchronous commit to at least one replica, and the latency cost is not optional.
See also
- Eventual ConsistencyEventual consistency guarantees only that if writes stop, all replicas eventually converge to the same value.
- Read-Your-Writes ConsistencyRead-your-writes consistency guarantees a client always sees its own completed writes, even while other clients may still see stale data.
- ShardingSharding splits a dataset across independent database instances by a partition key, so each shard holds a disjoint subset.
- Write AmplificationWrite amplification is the ratio of bytes physically written to storage to bytes logically written by the application.