Read Replica

A read replica maintains a copy of a database that can serve supported read workloads. It can shift scan CPU and I/O away from the primary, but copying changes still costs resources and the replica may be behind. A query that succeeds need not return the latest primary state.

In PostgreSQL physical replication, the primary sends WAL and the standby replays it. A committed change becomes available to a new eligible snapshot on that standby after replay, so asynchronous replication can return an older result while working as designed. Waiting for a standby at commit is not a single guarantee: with synchronous standbys configured, synchronous_commit=remote_write waits for the standby’s operating-system write, on waits for durable flush, and remote_apply waits for replay. Only the last of those waits establishes that the acknowledged transaction has been applied on the confirming standby. Route the subsequent read appropriately and account for its snapshot; an older transaction snapshot or another standby can still return older data. None of these acknowledgments promises visibility of later writes by other clients.

If the primary commits an order at 10:00 and replay reaches it at 10:02, an extraction at 10:01 can miss it. An application timestamp cursor must account for this visibility delay — the same gap that makes an extraction watermark skip rows when a commit becomes visible after the position has moved past its timestamp. Measure replay progress and query impact rather than assuming a fixed delay bound.

Long standby queries can conflict with WAL replay. In PostgreSQL, one cause is cleanup of row versions that no primary transaction needs but a standby query still sees. max_standby_streaming_delay bounds how long applying received WAL may wait for conflicts; it is not a fresh execution-time allowance for each query. Queries can be canceled when that delay budget is exhausted. hot_standby_feedback reports standby snapshot needs to reduce cleanup conflicts, at the cost of retaining dead rows on the primary. It does not prevent every cancellation: DDL or an exclusive lock can still conflict, and interrupted feedback leaves gaps in that protection. Choose settings from the observed conflicts, acceptable replay lag, and primary storage cost rather than assuming that all reporting queries will survive.

Logical CDC, promotion, and failover continuity require explicit support; change data capture has its own prerequisites. A replica is not an independent historical backup, because accidental changes may replicate too. Offloading scans can reduce primary contention, but replay and analytics still share replica resources; evaluate both capacity and workload isolation.

Further reading

• PostgreSQL hot standby
• PostgreSQL, Log-Shipping Standby Servers and synchronous replication