Read Replicas
Scale reads horizontally by fanning them out to replicas.
StarterData
A primary database takes all writes and streams them to one or more read replicas. Query traffic is routed to replicas, freeing the primary to focus on writes and reducing read latency near the load.
When to use it
- Read traffic significantly outweighs write traffic
- Slightly stale reads (replica lag) are acceptable for most queries
Trade-offs
- Replica lag means reads can be momentarily out of date
- Read-your-writes consistency requires routing that user's reads back to the primary
Components used
Managed App ServiceRelational Database
How it works
- A single primary accepts all writes and streams its changes to one or more read-only replicas.
- The application routes reads to replicas and writes to the primary, usually via separate connection strings or a proxy that inspects the statement.
- Replication is asynchronous by default, so a replica may lag the primary by milliseconds to seconds.
Used in the wild
- The first move when a read-heavy database starts saturating CPU.
- Isolating analytics and reporting queries so they cannot slow the transactional path.
- Geographic read locality, placing a replica near a distant user population.
Good to know
- The classic bug: a user submits a form, is redirected, the read hits a lagging replica, and their own change appears to have vanished. Read-your-writes routing — pinning a user to the primary briefly after a write — is the usual fix.
- Replicas scale reads but do nothing for write throughput. When writes are the bottleneck, sharding is the next step, not more replicas.
Related patterns
Retrieval-Augmented Generation (RAG)
Ground an LLM's answers in retrieved, up-to-date, private documents.
Vector Search + Rerank
Cheaply retrieve a broad candidate set, then precisely re-rank the top results.
Feature Store
Compute features once, serve them consistently to training and inference.
CQRS
Separate models and stores for writes and reads.