Why do big apps read from copies of their database?

Big apps read from copies of their database because one machine can only answer so many questions at once. The trick is to split the work. One primary database takes every write, such as a new post or a changed password, and logs it. Copies of that database, called replicas, receive the logged changes and mostly serve read requests. When the load is read-heavy, you can add replicas instead of buying an ever bigger machine, and so scale out beyond the capacity of a single database instance.

A read replica is a read-only copy of the primary. It can be looked at but never changed. Routing queries to replicas reduces the load on the primary, and it also protects it: business reporting and data warehousing queries can run against a replica rather than the production instance, so a heavy report does not slow down the shop.

There is a catch, and it can make a comment you just posted seem to vanish when you refresh. Replicas are usually updated asynchronously, so a change reaches them a little after it is committed. They may serve stale data because of replication lag, the delay in propagating changes from the leader. In PostgreSQL the delay is typically under one second if the replica can keep up, but running the same query on primary and replica at nearly the same moment can return different results.

Copies also help when things break. A read replica can be promoted to a standalone database as a disaster recovery solution if the primary fails. But the lag matters again: if the primary crashes, some committed transactions may not have reached the replica yet, and the data loss is proportional to the replication delay at that moment.