What is a read replica, and when should you use one?
Quick Answer
A read replica is a copy of the primary database kept in sync (asynchronously) that serves read-only queries. You route reporting and heavy read traffic to it so it doesn't compete with writes on the primary. The trade-off is replication lag — the replica can be seconds behind, so reads there are eventually consistent.
A read replica is a synchronised copy of the database that only handles reads. The point is to take the load of big reporting queries and read-heavy endpoints off the primary so writes stay fast. With SQL Server that's an availability group with a readable secondary, and you route to it with ApplicationIntent=ReadOnly. The catch is lag — the replica applies changes a bit behind the primary, so it's eventually consistent, which means right after a user saves something you still read from the primary for them, and send everything else to the replica. It's also a HA story since a secondary can be promoted. But I'd tune indexes and queries first.
- SQL Server: Always On Availability Groups with readable secondaries;
ApplicationIntent=ReadOnlyin the connection string routes to one. - Send a user's read immediately after their write to the primary (“read your own writes”), everything else can go to a replica.
- Replicas also provide high availability — a secondary can be promoted on primary failure.
- Don't reach for replicas before exhausting indexing and query tuning; they add real operational complexity.