Replication Lag (seconds), PostgreSQL

​

At a glance

How far behind the primary each streaming standby is, measured in seconds. Replication lag is the gap between “data committed on the primary” and “data visible on the replica”. When lag is zero (or sub-second) your read replicas are serving fresh data and a failover would lose nothing. When lag grows, two risks appear at once: read replicas start returning stale data to your application, and your recovery point objective (RPO) widens, because a primary failure now loses every transaction the standby has not yet caught up on. For a DBA this is the single most important number on a high-availability cluster.

​

Calculation

SELECT now() - pg_last_xact_replay_timestamp() AS replay_lag;

SELECT application_name, state,
       pg_wal_lsn_diff(sent_lsn,  replay_lsn) AS replay_bytes_behind
FROM pg_stat_replication;

High byte lag + low time lag   -> a burst of writes just happened; the
                                  standby is shipping fast and will catch up.
Low byte lag + high time lag    -> the PRIMARY is idle (no new WAL), so the
                                  "age of last replayed transaction" grows even
                                  though there is nothing to ship. Usually benign.
High byte lag + high time lag   -> the standby genuinely cannot keep up:
                                  network saturation, slow standby disk, or a
                                  long-running query on the standby blocking
                                  WAL replay (hot_standby_feedback contention).

​

Worked example

Diagnosis path:
  - standby-b healthy   -> primary is fine, WAL is being generated normally
  - standby-a high/high  -> something on standby-a cannot replay WAL fast enough
  - check pg_stat_activity on standby-a:
        a reporting query has been running 12 minutes with hot_standby_feedback on,
        and WAL replay is paused behind it to avoid replay conflicts.

1. The failover target lagging is a different severity from a read replica lagging. standby-b at 2s means a failover would lose ~2 seconds of writes, acceptable. If standby-b had been the one at 47s, the RPO exposure would be the headline and pre-empting a failover would be the priority. Always read which standby is lagging, not just the worst number.
2. A long query on a hot standby can stall replay. This is PostgreSQL-specific: the replica must choose between honouring a long read query and applying conflicting WAL. max_standby_streaming_delay controls the trade-off. If your read replicas run heavy reporting, expect lag spikes unless you tune this.
3. Time lag without byte lag is usually benign. Had the primary simply been idle overnight, the time lag would climb while byte lag stayed near zero. That is not an incident; it is arithmetic. The high-and-high pattern is what makes this a real event.

​

Sibling cards to read alongside

​

Reconciling against the source

On the primary, the master view is pg_stat_replication:

SELECT application_name, state, sync_state,
       pg_wal_lsn_diff(sent_lsn, replay_lsn) AS replay_bytes_behind,
       write_lag, flush_lag, replay_lag
FROM pg_stat_replication;

The replay_lag interval column (PostgreSQL 10+) is the primary’s own estimate of time-based lag and is the closest native equivalent to this card. On each standby, SELECT now() - pg_last_xact_replay_timestamp(); gives the replica’s view of its own staleness, and SELECT pg_is_in_recovery(); confirms it is still a standby.

Amazon RDS: the ReplicaLag CloudWatch metric (seconds) is the native equivalent for read replicas. Aurora PostgreSQL uses AuroraReplicaLag (milliseconds), which is typically far lower because Aurora replicates at the storage layer, not via WAL streaming. Google Cloud SQL: the database/replication/replica_lag metric in Cloud Monitoring. Azure Database for PostgreSQL: the physical_replication_delay_in_seconds metric.

​

Known limitations / FAQs

​

Tracked live in Vortex IQ Nerve Centre