Database Replicas: Read Replicas vs Failover Replicas

Read replicas and failover replicas look similar; serve different purposes. Conflating them creates surprises.

Why distinguish

Read replica: serves read traffic; performance lag tolerated; not failover-ready.

Failover replica: standby; minimal lag; ready to take over.

Four criteria

• 1. Lag tolerance.
• 2. Promotion-ready.
• 3. Resource sizing.
• 4. Application connection.

Configuration differences

Read replica: async replication OK; smaller instance fine; app connects via different endpoint.

Failover replica: synchronous if possible; same size as primary; app discovers via DNS / endpoint switch.

Conflation mistake

Treating a read replica as failover-ready: when primary dies, you fail over to a replica that lags by minutes; data loss.

Treating a failover replica as read-traffic source: it can lag; promotion-readiness compromised.

Antipatterns

• Read replica as failover. Data loss risk.
• Failover replica handling read load. Promotion delayed.
• One replica for both. Confused responsibilities.

What to do this week

Three moves. (1) Apply this pattern to your most-loaded table. (2) Measure query latency / write throughput before/after. (3) Document the win and the constraint so the next refactor inherits the knowledge.