Read replica

What is a read replica?

A read replica is a read-only copy of a database that takes over read traffic from the primary. The primary handles every write. The replica receives those changes as a stream and answers queries such as reports, exports and dashboards. Applications connect to it like any database, except they cannot write to it. A sales dashboard can run against a replica while the webshop keeps writing orders to the primary, so a heavy report never competes with a customer checkout.

Managed services build this in: Amazon RDS and Azure Database for PostgreSQL both add replicas on top of the replication the engine already ships. A replica keeps the primary's schema, a transactional OLTP layout rather than the modelled tables of a data warehouse, so for heavier OLAP reporting teams usually move data into a warehouse with change data capture instead.

Asynchronous versus synchronous replication

Most read replicas replicate asynchronously. The primary commits a transaction, sends the change to the replica, and does not wait for it to confirm. In PostgreSQL streaming replication this is the default, and the delay between a commit on the primary and that row appearing on the replica is usually under a second.

Synchronous replication is the other mode. The primary waits until a standby has written, or even applied, the change before the commit returns. That keeps the last committed transactions safe if the primary dies, but every write pays for a network round trip. It is also the split between a failover standby and a read replica: an RDS Multi-AZ standby replicates synchronously and serves no reads, while a read replica replicates asynchronously to spread read load without holding up writes.

Replication lag and stale reads

Because replication is asynchronous, the replica runs slightly behind. That gap is called replication lag. On a quiet system it is milliseconds. During a write spike, a network problem or a bulk import it can stretch to seconds or minutes.

This is the consequence people actually hit. A user changes their address, and the app reads it straight back from a replica that is two seconds behind, so the screen still shows the old value. The write succeeded, the read looks wrong. This is the read-your-writes problem, and it is why some reads have to go to the primary: anything a user just changed and expects to see immediately. Reports and dashboards tolerate a small lag, as long as everyone knows how fresh the data is.

A read replica is not a backup

A replica copies whatever the primary does, mistakes included. Run a DELETE without a WHERE clause on the primary and replication applies the same delete on the replica moments later. The rows are gone in both places. A backup with point-in-time restore is what lets you rewind to just before the delete; a replica cannot, and on Azure you cannot even take a backup from a replica or restore one from it.

A replica can still be part of disaster recovery: put one in another region and promote it to a standalone primary if the original fails. That covers a data-centre outage, not a bad query. Two siblings sit close by here, the connection pool in front of your database and disaster recovery with its RPO and RTO targets, and both come up the moment you route reads to a replica in production.