What a read replica does
A database replica is a copy of data maintained from another database instance, often called the primary. In a common setup, the application sends writes to the primary while one or more replicas receive changes and answer read queries. The primary might record a new order, for example, while a replica serves a product listing or a report. Replication describes the process of moving those changes; a read replica is a database instance used to serve reads.
The details vary by database system. Changes may be shipped as a log of operations or through another database-specific mechanism. Replication may be asynchronous, meaning the primary can acknowledge a write before the replica has applied it, or synchronous, meaning a write waits for a specified replica acknowledgement. Neither label alone tells you exactly when a particular query will see new data: acknowledgement rules, network conditions and replica processing all matter.
Where replicas help
Read replicas are useful when reads account for a substantial share of database work and can be routed away from the primary. A small team might send search-result pages and dashboard queries to a replica, leaving more primary capacity for transactions. Separating some long-running reports from routine application queries can also reduce contention, although expensive queries can still overwhelm the replica itself.
A replica in another location may reduce the distance between some users and their reads, but it can add delay to replication and does not make writes local. Replicas can also support maintenance or recovery plans in systems that allow a replica to be promoted to a primary. That possibility is not the same as automatic failover: promotion, application reconnection and checks that the candidate has the required data all need a plan.
The consistency trade-off
With asynchronous replication, a replica can briefly return an older value after the primary accepts a write. This delay is called replication lag. Imagine a user changes a profile name and immediately reloads the page. If the reload reads from a lagging replica, the old name may appear even though the update succeeded. Lag can grow when the replica cannot apply changes as quickly as the primary produces them, or when connectivity is disrupted.
Decide which reads can tolerate that delay before routing them. A public catalogue may accept a short-lived stale result; a confirmation screen that must reflect a just-submitted change may not. One approach is to send consistency-sensitive reads to the primary. Another is to use a database-supported method that waits until a replica has applied a particular write. Application caching can also return stale data, so a consistency problem is not necessarily caused by replication alone.
What replication does not solve
Replicas are not a substitute for backups. If an application accidentally deletes records and the deletion is replicated, the copies may lose those records too. Backups, retention and a tested restore procedure address a different need: recovering an earlier state. A replica also does not automatically protect against every outage. If the primary fails, recovery depends on the replication design, the state of available replicas and how clients are redirected.
Adding replicas does not increase the primary's write capacity in a conventional single-primary design. Each additional replica needs storage, computing resources and network transfer, while the primary may do extra work to support replication. Routing also becomes more complicated: the application or a database proxy must know which requests need the primary and which may use a replica. More instances can help with read demand, but they create more components to secure and operate.
A practical way to decide
Start by identifying the actual bottleneck. If slow pages come from missing indexes, inefficient queries or excessive requests, a replica may copy the problem rather than fix it. Measure read and write load, inspect slow queries, and classify application reads by their tolerance for stale data. Then test a limited set of suitable reads on a replica before moving more traffic.
Monitor replica availability and lag, and test what the application does when the replica is behind or unreachable. Document which instance accepts writes, how a replica would be promoted, and how backups are restored. Read replicas work best as a deliberate capacity and availability tool: they can take useful work off the primary, provided the team designs for delayed data and understands that a copy is not a complete recovery strategy.
