What is a read replica?
A read replica is a copy of a database that receives a continuous stream of changes from the primary and answers read-only queries. Writes go to the primary; the primary ships its changes to the replica; the replica serves SELECTs. Most managed database services will create one for you with a checkbox.
Replicas do two jobs. They spread read load across more machines — a form of horizontal scaling — and they give you a warm copy to promote if the primary fails.
Why this matters for analytics
The single most common reason to add a replica is analytics. A production database is tuned for OLTP: thousands of small, fast transactions that keep your app responsive. An analytical query is the opposite — it scans millions of rows, aggregates them, and doesn’t care much about latency. Run enough of those against the primary and checkout gets slow.
Pointing your BI tool at a replica instead is one of the cheapest fixes available. The data is the same, the SQL is the same, but a badly written query with a missing filter now hurts a machine nobody’s shopping cart depends on. If your data volumes are modest and you don’t have a warehouse yet, a replica is often the right first step — and a lot less work than building an ETL pipeline.
What a replica does not fix
A replica is still a row-oriented transactional database with your application’s normalized schema. It doesn’t make analytical queries fast, it just makes them somebody else’s problem. When those queries start taking minutes, the answer isn’t another replica — it’s a columnar analytical database or data warehouse with a model built for the questions you’re actually asking.
Replication lag
Replication is asynchronous in most setups, so the replica is always slightly behind — usually milliseconds, occasionally much more when the primary is under heavy write load or the replica is busy serving expensive scans.
This is fine for most reporting and confusing for some of it. Things to keep in mind:
- “Today’s” numbers may not be complete. A dashboard refreshed at 9:00 may miss writes from 8:59:58.
- Support workflows break in obvious ways. A rep who updates a record in the app and immediately checks a dashboard may not see the change.
- Lag itself is worth monitoring. If it climbs steadily, either the primary is writing faster than the replica can apply, or your analytics queries are starving it.
Read-only means read-only
You can’t write to a replica, which is a feature: it removes a whole class of accident. It also means anything your BI tool needs to persist — scratch schemas, materialized results, persisted models — has to live somewhere else, so check that before you flip the connection over.
Related terms
Further reading
Put it to work
- Observability analytics — Overview
- Service availability dashboard — Dashboard
- Resource utilization — Metric
