Read replica
A read-only copy that follows the main database and handles SELECT traffic, with the tradeoff that fresh writes may arrive late.
See it
What it is
A read replica is a database copy that continuously receives changes from a primary and serves read-only queries. It can move dashboards, searches, or other heavy reads away from the primary, leaving more capacity for writes. Amazon RDS and PostgreSQL streaming replication are common ways to run one.
Reach for one after measuring that read load, not inefficient queries or missing indexes, is the real bottleneck. Separate connection pools let the application route tolerant reads to replicas and writes to the primary. Replicas in another region can also bring some reads closer to users.
Gotcha: most read replicas update asynchronously, so a successful write may not appear there immediately. Read-after-write screens, permission checks, and money movement should stay on the primary unless the app has an explicit consistency strategy. A replica also repeats accidental deletes, so it does not replace backups.
Ask AI for it
Add an Amazon RDS for PostgreSQL read replica and route application traffic through separate primary and replica connection pools. Send writes, transactions, permission checks, and read-after-write requests to the primary; send only explicitly stale-tolerant SELECTs to the replica. Fall back to the primary when the replica is unhealthy or lag exceeds 5 seconds, and expose pool usage plus pg_last_xact_replay_timestamp() as metrics. Provide Terraform, routing code, and tests proving that no write reaches the replica.