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.

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. Measure replay progress and query impact rather than assuming a fixed delay bound.

Long reads can conflict with recovery or delay cleanup, depending on the engine and settings. Logical CDC, promotion and failover continuity require explicit support. A replica is not an independent historical backup: accidental changes may replicate too.

Reference: PostgreSQL hot standby.