Replication lag
How far a database copy trails the primary, explaining why a write can succeed while a read from the replica still shows old data.
See it
What it is
Replication lag is the gap between a change becoming visible on the primary database and the replica applying that change. The gap can be measured as time, log bytes, or a replication position. Network delay, bursty writes, slow replica disks, and long-running queries that block replay can all make it grow.
Watch it when replicas serve user reads, provide failover capacity, or feed downstream systems. In PostgreSQL, pg_stat_replication exposes sent, write, flush, and replay log sequence numbers, and pg_wal_lsn_diff reports the byte distance between them.
Gotcha: a clock-based query can claim lag is growing while an idle primary has produced no new work. Monitor both time and WAL position, or write a small heartbeat row, and alert against the freshness promise the product actually makes. Routing stale-sensitive reads away from a lagging replica is often safer than waiting for a fixed timeout.
Ask AI for it
Instrument PostgreSQL streaming replication lag from pg_stat_replication using sent_lsn, write_lsn, flush_lsn, replay_lsn, and pg_wal_lsn_diff. Export byte lag and replay-time lag to Prometheus, add a once-per-second heartbeat table so an idle primary is not mistaken for growing lag, and alert when lag exceeds 64 MB or 5 seconds for 10 minutes. Make the read router fall back to the primary for stale-sensitive requests while the alert is active, and include Grafana panels plus a load test that proves the alert and fallback.