**The thing in one sentence:** A read replica is a second live copy of our database that answers "show me" requests (page views, searches, dashboards) so the heavy reading doesn't slow down the main copy that records changes. **The mental model:** A busy library with one librarian who handles both checkouts and returns. The line backs up because one person is doing two different jobs, and the quick tasks wait behind the slow ones. Add a second librarian who only handles checkouts, and the returns clear faster. The analogy holds for "two people splitting different work." It breaks on one point: the second librarian learns about each return a moment after it happens, not instantly. That delay matters below. **The 2-3 things that actually matter:** - Most of our database load is reads. Every page view, search, and dashboard render is a read, so moving them to the replica is a real cost and speed lever, not a marginal one. - The replica runs slightly behind the primary, usually by milliseconds. Fine for almost everything; for the few reads that must be exactly current (a balance shown right after a payment) we deliberately send those to the primary. - A replica is not a backup. It is a live second copy serving traffic. We still keep real backups separately, and we still pay for them. **What this is often confused with:** - A backup. A backup is a point-in-time copy you restore from after something breaks. A replica is always running and serving requests. Different job, and this is the question a board member is most likely to ask. - Sharding. Sharding splits the data across databases (some customers here, others there). Replication keeps the same data on two databases. We are doing the second one. - A cache. A cache keeps the most-requested answers in memory and is faster, but only for popular data. The replica covers the whole dataset. **What the explanation leaves out:** - How replication works underneath (write-ahead logs, streaming, lag monitoring). Real, but not load-bearing for a cost decision. - Synchronous versus asynchronous replication. We use async; if the board asks, the one-line answer is that the alternative buys stricter consistency at the cost of slower writes, and the tradeoff favored async for us. - The dollar figures, which sit in the separate budget line.