RDS Read Replicas
18 min
An RDS read replica is a read-only copy of the primary database, kept in sync via one-way replication — changes flow FROM the primary TO each replica, never the other direction. This is exactly why writes must always target the primary: a write sent to a replica would create data with nowhere to propagate to, immediately diverging from the source of truth. Reads, on the other hand, can be routed to whichever replica currently has the lowest latency, spreading read load across several instances.
def route_query(is_write, replicas_latency_ms):
if is_write:
return "primary"
if not replicas_latency_ms:
return "primary"
return min(replicas_latency_ms, key=replicas_latency_ms.get)
This read/write split is exactly what a connection-pooling proxy (like RDS Proxy, or an app-level read/write router) does automatically -- application code just issues queries, and the routing layer decides primary-vs-replica based on whether it's a write, completely transparent to the caller.
Write `route_query(is_write, replicas_latency_ms)`: writes always go to `'primary'`. Reads route to whichever replica in `replicas_latency_ms` (a dict of replica name to latency) has the LOWEST latency — or `'primary'` if the dict is empty.
Why must WRITES always go to the primary database instance, never a read replica, in a typical RDS replication setup?
You can route reads and writes correctly in a primary/read-replica setup, and understand why writes can never target a replica under one-way replication.