Replication Lag
Replication lag is the delay between a primary write and its visibility on replicas, causing stale reads and missing read-after-write guarantees unless reads are routed deliberately.
Definition
Replication lag is the time or transaction distance by which a replica trails its primary. In asynchronous replication the primary acknowledges writes before replicas apply them, so a read from a replica may miss a recent write. Lag grows under write bursts, network issues, or slow replica apply. Synchronous replication reduces lag at the cost of write latency and availability.
Context and scope
Read replicas scale reads but introduce consistency choices. Applications that route all reads to replicas can show a user their own write as missing, or move backward in time between requests. Lag matters for dashboards, feeds, account pages, and any workflow with read-after-write expectations.
Common misconceptions
- Replicas are always up to date — asynchronous replicas can lag by seconds or minutes
- Lag only matters for analytics — user-facing read-after-write flows are affected too
- Adding replicas reduces lag — more replicas can increase primary load and apply contention
Anti-patterns
- Sending a user's read immediately after their write to a lagging replica
- Load-balancing reads across replicas without tracking consistency requirements
- Ignoring lag metrics until users report missing data
Related concepts
Related examples
Authoritative source
Read-after-write failure
A user updates their profile; the write goes to the primary. The next page load reads from a replica that has not applied the change, so the old profile appears. A refresh a second later shows the new value. The data is not lost; the read was routed to a stale copy.
Mitigations
- Route reads that must reflect a user’s own writes to the primary for a short window.
- Track a write timestamp or log sequence number and require a replica to have caught up.
- Use sticky sessions or per-user read routing during a session.
- Accept bounded staleness for feeds and analytics, and label the freshness.
-- PostgreSQL: inspect replica lag
SELECT client_addr, state, sent_lsn, replay_lsn,
pg_wal_lsn_diff(sent_lsn, replay_lsn) AS lag_bytes
FROM pg_stat_replication;When to choose replicas
Use replicas for read scaling and geographic latency when the application can tolerate bounded staleness. Compared to synchronous replication, asynchronous replicas keep write latency low but weaken read guarantees. Compared to caching, replicas hold the full dataset and apply writes, but still lag.
Pitfalls
A replica can lag more during failover, bulk loads, or long transactions. Health checks that only test connectivity miss apply lag. If a read requires the latest write, make that requirement explicit in the data-access layer rather than relying on the load balancer’s choice.