Stop 06 · Database ServicesTopics · 5/10

Read Replicas & Scaling Reads

In short

Most apps read far more than they write. Thousands of people browse products, a few hundred buy. Read replicas let those browsers hit copies of the database, leaving the main one free for writes.

Creating read-only copies of a database to offload read traffic from the primary instance — a common pattern for read-heavy applications, distinct from the failover-focused replication in high availability.

The blob character pins identical notices on several boards along a corridor.

Think of it like this

Copies of the notice

The principal writes one notice. The office pins photocopies on every floor so students don't crowd the main board. If the notice changes, the copies get updated a little later. That's a read replica.

Watch it happen

Writes to one, reads from many

App

Primary

Replica 1

Replica 2

UPDATE price=499

1/5All writes go to the primary. It's the only copy that accepts changes.

The big ideas

What you need to know

Split reads and writes

Send writes to the primary endpoint and reads to replica endpoints. Your app or a proxy decides which goes where.

Asynchronous means lag

Replicas trail the primary a little. Reading right after writing may show old data.

Different from Multi-AZ

A Multi-AZ standby is for failover and takes no reads (in classic RDS). Replicas are for scaling reads.

Replicas in other regions

A cross-region replica speeds up reads for faraway users and can be promoted during a disaster.

See it in code

Walk through the code

1import { Pool } from "pg";2 3const writer = new Pool({ connectionString: process.env.DB_PRIMARY_URL });4const reader = new Pool({ connectionString: process.env.DB_REPLICA_URL });5 6export async function updatePrice(id: number, price: number) {7  await writer.query("UPDATE products SET price = $1 WHERE id = $2", [price, id]);8}9 10export async function listProducts() {11  const { rows } = await reader.query("SELECT id, name, price FROM products LIMIT 50");12  return rows;13}

1/3Separate pools for the writer endpoint and the reader endpoint.

Two connection pools: one for the primary, one for replicas. Reads that must see the latest write should still use the writer.

Save yourself the pain

Common mistakes

Oops

Reading from a replica right after a user saves their profile.

Do this instead

Read-your-own-writes should hit the primary, or the user may see their old details and think the save failed.

Oops

Adding replicas to fix slow writes.

Do this instead

Replicas only help reads. For write pressure, tune queries, scale the primary up or rethink the data model.

Your mission

See replication lag

~40 min

Quick check

A product page shows the old price for a second after an admin changed it. Most likely cause?

Go deeper

1Create a read replica of a sample database and route a read query to it.
2Learn why read replicas introduce replication lag and why that matters for consistency-sensitive reads.
3Understand the difference between scaling reads (replicas) and scaling writes (sharding, a harder problem).