Read replicas and replication lag: what stale reads look like and how to bound them

What it is

In PostgreSQL streaming replication the primary sends write-ahead log records to standbys, which replay them; a hot standby also serves read-only queries. Replication is asynchronous by default: a commit returns before any standby has the data. The documentation (cited) describes synchronous_commit levels that make a commit wait for a standby to have written, flushed or, with remote_apply, replayed the transaction so that it is visible to queries there, which the documentation says allows load balancing with causal consistency in simple cases; the standbys involved are named in synchronous_standby_names.

Replay and queries compete. The hot standby documentation (cited) explains that WAL application can conflict with running queries (for example when a row a query needs has been cleaned up on the primary); after max_standby_streaming_delay the conflicting query is cancelled, and hot_standby_feedback prevents the primary's VACUUM from removing rows a standby still needs, at the cost of bloat on the primary. Monitoring uses pg_stat_replication on the primary and the replay position functions (cited), such as pg_last_wal_replay_lsn(), on the standby.

Why it matters

The typical bug: a user submits a form (write to primary), the next page lists items (read from replica) and the new item is missing; a retry shows it. Background jobs that read from a replica act on stale state. These are not rare corner cases but the normal behaviour under lag.

How to apply

• Classify reads: after-write reads in the same user flow go to the primary or stay pinned to it for a short period after any write by that session; dashboards and search can use replicas freely.
• For a strict read-your-writes check, record the primary's commit position and let the replica read proceed only when its replay position has reached it.
• Give analytical replicas a large standby delay so long queries are not cancelled; keep the delay short on replicas that serve latency-sensitive reads.
• Alert on lag in bytes and seconds, and on the number of query cancellations on each standby.
• Use synchronous modes only for the standbys and workloads where the added commit latency and the risk of stalled commits when a standby is down are accepted.

Pitfalls

A proxy that routes statements by type (every SELECT to a replica) can send a transaction's own reads away from the primary unless it tracks the transaction. A replica promoted during failover may lag behind the old primary, so recent commits can be lost with asynchronous replication. Lag under heavy write load grows exactly when reads are heaviest.