Read replicas show up early in a lot of "how to scale your database" advice, which leads founders to reach for them well before the actual bottleneck justifies the added complexity. They solve one specific problem well — and create a few new problems of their own — so it's worth being precise about when they're the right tool.
What a read replica actually solves
A read replica is a continuously-updated copy of your primary database that can serve read queries (SELECTs) while all writes still go to the primary. If your database is CPU- or I/O-constrained specifically because of read query volume — heavy reporting queries, a read-heavy public API, dashboard queries — a replica lets you offload that read load onto separate hardware, leaving the primary free to handle writes.
The signal that actually justifies one
The test isn't "we're growing" or "we might need this eventually" — it's a specific, observed pattern: your primary database's CPU or I/O is measurably strained, and when you break down the query load, reads (not writes) are the dominant cause. If writes are the bottleneck, a read replica does nothing for you, since writes still all funnel through the single primary regardless of how many replicas exist. This is the single most common mistake in reaching for replicas prematurely — assuming general "database load" is read load without actually checking.
What replication lag means for your app
Replication is asynchronous by default in most setups, meaning there's a small delay (usually milliseconds, occasionally longer under load) between a write landing on the primary and that same data being visible on the replica. This creates a real application concern: a user who just submitted a form and is immediately redirected to a page that reads from a replica might briefly not see their own change. Handling this usually means routing certain reads — particularly "read your own write" scenarios right after a user action — back to the primary deliberately, rather than sending every read to a replica indiscriminately.
What gets harder once you add one
Beyond replication lag, a replica adds: another server to patch, monitor, and back up (or exclude from backups deliberately, since it's a copy); connection routing logic in your application to decide which queries go where; and a new failure mode where the replica falls behind or disconnects and needs its own alerting, distinct from primary database alerting covered in our monitoring guide. None of this is prohibitive, but it's real ongoing operational surface that a single-database setup simply doesn't have.
Alternatives worth trying first
Before adding a replica, it's worth exhausting cheaper options: adding or fixing database indexes for your actual slow queries (a shockingly common fix that solves what looks like a scaling problem but is actually a missing-index problem), caching frequently-read, rarely-changed data in Redis or an in-process cache, and vertically scaling the primary itself, which is often cheaper and always simpler than adding a second database server — consistent with the general vertical-first approach in our scaling roadmap.
Frequently asked questions
How do I actually check whether my load is read-heavy or write-heavy?
Most databases expose query statistics that break this down — Postgres's pg_stat_statements extension, for instance, shows call counts and total time per query, which you can categorize into reads and writes. Don't guess; check before committing to a replica.
Can a read replica also serve as a backup?
Not as your only backup — a replica mirrors data corruption or accidental deletion just as faithfully as it mirrors legitimate writes, near-instantly. It's a scaling and read-availability tool, not a substitute for the point-in-time backups covered in our backup guide.
Is it hard to add a replica later if I don't need one now?
No — this is one of the more reversible infrastructure decisions. Most managed database services and self-hosted Postgres/MySQL setups support adding a replica to an existing primary without downtime, so there's little cost to waiting until the read-heavy signal above actually shows up.