What is the difference between a primary and a replica database?

The primary takes all the writes and holds the newest data. A replica copies its changes and answers reads, but usually takes no writes. If the primary fails, a replica can take its place.

Module 4 · Storing Data That Keeps Growing · Lesson 17 of 35

What is a read replica? Copies that take the reading load

12 minFree System design course · Beginner to intermediateLesson 4.4By Saket Bhatnagar

Researched and drafted with AI, reviewed and edited by Saket Bhatnagar.

In short

What is a read replica? It is a copy of the main database that answers reads, leaving the main one free for writes.
Changes reach the copies a little later, so a brand-new write may not show yet.
Copies add reading power, not writing power, and one can take over if the main database dies.

Soon

Video lesson · coming soon

What is a read replica? Copies that take the reading load

Lala, your AI mentor, will walk you through this lesson in a short animated video. Until then, everything is here to read and try.

01 My booking disappeared
02 Photocopies of the topper’s notes
03 One primary, two replicas
04 The write, the gap, the fix
05 Where 1,000 operations go
06 Draw your primary and replicas

That morning Zoya adds two copies of SeatJaldi’s relational database, and “My bookings” is fast again. Then the noon sale for match 42 begins, and users start posting: “My booking disappeared!”

Arjun books a ticket himself, pays, and taps “My bookings” straight away. The list is empty. Meera is on the phone with a very annoyed user.

Zoya looks in the main database. Booking BK-10431 is there, safe and complete. “The data exists,” she says slowly. “So why does the page say it does not?”

What is a read replica?

A read replica is a copy of the main database that answers reads while the main one keeps taking the writes. Most apps read far more than they write.

Keep one line in your head: copies spread reads but always trail the original a little.

Writes go to one place: the primary.
Reads can go to any replica, so reading power grows with each copy.
Each replica is a little behind, so it can miss the newest change.

One primary, two read replicas

Drag to explore

The app sends writes and a user’s fresh reads to the primary, other reads to the replicas. Changes reach the replicas about 300 ms later here.

Those “Late copy” arrows are called replication. The primary sends each change, and every replica repeats it.

You post a comment, reload, and it is missing. A second later it appears. The reload read a copy that was behind.
You change your profile photo, but a friend sees the old one for a while. Their read hit a copy still catching up.
The page says “Your orders (0)” right after you order, then a refresh shows it.

What is replication lag, and why did Arjun’s booking disappear?

Replication lag is how far a replica is behind the primary, and a read that lands in that gap does not see the newest write. It is the copier’s delay.

Try it yourselfFollow one booking from the primary to the replicasStep through a write, a read that misses it, the fix, and a crash. Numbers are made up.

How do you fix a read that misses your own write?

Read the user’s own recent writes from the primary for a few seconds. That gives read-your-writes: you always see what you saved. If you wrote a page a moment ago, you ask Ritika for her notebook, not the photocopy.

Three ways to handle a read that misses a fresh write
Fix	What it does	What it costs
Read your own writes from the primary	Your reads go to the primary for 10 s after you write	A little more work for the primary
Wait for the copy	The read waits for the replica to catch up	Slower pages, worse when lag grows
Send every read to the primary	No replica reads at all	Never stale, but the primary is crushed again

What just happened? Zoya picked the first row. Only people who wrote in the last 10 seconds read from the primary. A stranger who sees your booking 300 ms late is not hurt.

What happens when the primary dies, and what should engineers watch?

When the primary dies, a replica takes over as the new primary. Changes it had not received can be lost, like a classmate carrying on from a copy without Ritika’s last page.

How much is lost depends on how the primary copies. With asynchronous copying, it says “saved” without waiting for replicas. Writes stay fast, and PostgreSQL’s docs say the delay is typically under one second if the replica keeps up.

The price: a crash loses the changes still inside the lag. With synchronous copying, each write waits until a replica has it on disk, so failover loses nothing.

Synchronous costs time: every write waits at least one round trip to the replica.
On disk is not yet visible: with PostgreSQL’s default synchronous setting, a replica read can still miss the change. The remote_apply setting waits until reads see it.
Synchronous can stall: if the only replica the primary waits for crashes, writes hang. They resume when it returns or an engineer tells the primary to stop waiting.
PostgreSQL replicas answer reads and turn down writes.

Watch the lag on a dashboard, because it can jump. By default PostgreSQL lets a slow report on a replica pause copying for up to 30 seconds, longer than Zoya’s 10-second window. So when lag is high, read from the primary until it falls. This SQL measures it:

sql

-- run on a replica
SELECT now() - pg_last_xact_replay_timestamp() AS replication_delay;

What just happened? It shows the time since the replica applied its last change. If the primary is quiet, this grows though nothing is wrong. On a primary, or a replica that has applied nothing, it is empty.

Keep the last write time in the session store, because the next tap may reach a different app server. This covers one login only: Arjun’s second phone could still see the old list.

javascript

const RECENT_WRITE_MS = 10000; // design choice: well above normal lag

function pickDatabase(session, now, primary, replica) {
  const last = session ? session.lastWriteAt : undefined;
  if (last === undefined || last === null) return replica; // never wrote
  const lastMs = typeof last === 'number' ? last : Date.parse(last);
  if (Number.isNaN(lastMs)) return primary; // unreadable time: play safe
  return now - lastMs < RECENT_WRITE_MS ? primary : replica;
}

// after a booking is saved: session.lastWriteAt = Date.now();

What just happened? A user who wrote 50 ms ago gets the primary. A user who never wrote, or wrote 12 seconds ago, gets the replica. If the saved time cannot be read, the code plays safe and uses the primary.

PostgreSQL promotes a replica only when told to. Spotting the dead primary, and stopping it from coming back as a second primary, needs a separate program. Drill it: switch to a replica, list the lost changes, and check the app servers find the new primary.

Try it yourself

Split 1,000 operations
Assume 9 of every 10 database operations are reads. How many of 1,000 are reads, and how many are writes?
Move reads to the replicas
Two replicas share 90% of the reads evenly. How many does each take?
Count the primary’s work
Add the writes and the reads it keeps.
Count each replica’s work
Add its reads and the writes it must apply. Count each applied write as one operation, an assumption.
Check your work
Right answers: 900 reads, 100 writes, 405 reads per replica, 190 operations on the primary, 505 on each replica.

What just happened? The primary fell from 1,000 operations to 190, about five times lighter. If you said 405 per replica, look at step 4: every copy repeats all 100 writes.

Back to Arjun’s missing booking. His page read a photocopy at 50 ms, but Ritika’s new page reached it at 300 ms. With Zoya’s fix, users read their own fresh writes from the primary, and the posts stop.

The replicas still take 90% of the reading, so the notebook stays free for writing. If each replica is a ₹9,000-a-month server, an assumption, the two cost ₹18,000 a month.

Then Meera reads out her plan for the national sale. Zoya works it out on the whiteboard, about 830 bookings a second, and frowns. “Writes are the next wall: 50,000 bookings a minute at the national sale and 2 TB of history across 6 states. One primary cannot hold or take it all. What do we do about writes?”

Check yourself

Arjun pays, and 50 ms later the page asks a replica that is 300 ms behind. What does the page show?

Pick an answer to see why it is right or wrong.

Check yourself

Two replicas now take 90% of the reads. What happens to the writing work?

Pick an answer to see why it is right or wrong.

Check yourself

Which read should NOT be sent to a replica?

Pick an answer to see why it is right or wrong.

Remember these three

Copies spread reads but always trail the original a little.
Read a user’s own fresh writes from the primary, and never decide a write from a replica read.
Replicas add reading power and a copy for failover, not writing power.

Questions people ask

What is a read replica?: A read replica is a copy of the main database that answers reads, so the primary has less to do. It gets each change a little later, so it can briefly miss new data.
What is replication lag?: Replication lag is how far a replica is behind the primary, often a fraction of a second. A read inside that gap misses the newest write, so a fresh booking can seem to vanish.
What is the difference between a primary and a replica database?: The primary takes all the writes and holds the newest data. A replica copies its changes and answers reads, but usually takes no writes. If the primary fails, a replica can take its place.

What is a read replica?

What is replication lag, and why did Arjun’s booking disappear?

How do you fix a read that misses your own write?

What happens when the primary dies, and what should engineers watch?

Try it yourself

Check yourself

Questions people ask

Sources and further reading