Read Replicas: Scale Out Your Database Reads

Why it exists

A single database instance can only handle so much traffic. For applications with many more reads than writes, the database can become a bottleneck, slowing everything down for all users. Read replicas were created to solve this by offloading read queries from the primary database, allowing it to focus on writes.

The mental model

Think of a read replica as a dedicated "reference copy" of your main database. The main database is the "master copy" where all changes (writes) happen. The reference copies are kept up-to-date from the master, but their only job is to answer questions (reads), freeing up the master to focus on recording new information.

How it works

When you create a read replica, the system first takes a snapshot of your primary database and creates a new, separate instance from it. Then, it uses the database engine's built-in asynchronous replication. This means any change made to the primary database is eventually sent to the replica to be applied. Because it's asynchronous, there's a delay, known as "replica lag," between when data is written to the primary and when it appears on the replica. Applications connect to the replica using a standard database connection but can only perform read operations.

When to use it

Use read replicas for read-heavy workloads where you can tolerate a small amount of data staleness. This is common in business intelligence tools, reporting dashboards, or public-facing websites where many users are browsing content (reading) but few are creating it (writing). They also enhance availability; a replica can be promoted to a primary instance in a disaster recovery scenario if the original primary fails.

When not to use it

Do not use read replicas when you need immediate read-after-write consistency. For example, after a user changes their password, you must read from the primary to verify the new one; reading from a stale replica would fail the login. The potential for replica lag makes them unsuitable for workflows that require immediate confirmation of a write. They are a complement to, not a replacement for, Multi-AZ deployments for high availability.

One canonical example

A popular e-commerce website gets millions of visitors browsing its product catalog. This is a massive read load. By directing all product page views, searches, and category listings to a set of read replicas, the primary database is freed up to handle the much lower volume of critical write operations, such as placing an order or updating inventory. This keeps the site fast for browsers and ensures that checkout processes remain reliable.