Read Replicas for Database Load Distribution

When a single database server handles both reads and writes, response times increase and CPU/IO saturate as traffic grows. Read replicas distribute the database load by keeping write operations on the primary (master) while routing read queries to one or more replica servers. Since most web applications have an 80/20 or 90/10 read/write ratio, adding read replicas alone can increase capacity by 3-5x. This guide covers read replica setup for PostgreSQL and MySQL, replication lag management, and application-level load balancing strategies.

How Read Replicas Work

Primary (Master)

Accepts all write operations (INSERT, UPDATE, DELETE). Streams changes to replicas via WAL/binlog.

Replica (Slave)

Serves only read queries (SELECT). Applies changes from primary asynchronously or synchronously.

Replication

Async replication provides low latency but may have brief data delay (lag). Sync replication guarantees consistency but increases write latency.

PostgreSQL Streaming Replication

bash - Replica setup

# Take base backup from primary
pg_basebackup -h primary-ip -D /var/lib/postgresql/16/main \
  -U replicator -Fp -Xs -P -R

# -R flag creates standby.signal and primary_conninfo
# Start the replica
sudo systemctl start postgresql

# Check replication status (run on Primary)
SELECT client_addr, state, sent_lsn, replay_lsn,
       sent_lsn - replay_lsn AS lag_bytes
FROM pg_stat_replication;

⚠️ Replication Lag: With async replication, the replica can lag behind the primary by milliseconds to seconds. If a user writes data and immediately reads it, they may see stale data. For critical reads (e.g., order status after payment), read from the primary.

For PostgreSQL optimization, check our PostgreSQL Performance Optimization guide. For connection management, see our PgBouncer guide. The PostgreSQL Replication Documentation is a useful additional resource.

Frequently Asked Questions

How many read replicas should I add?

It depends on your read traffic. For most applications, 1-2 replicas are sufficient. Each replica should have the same hardware as the primary. Adding more replicas increases WAL sending load on the primary - consider cascading replication for more than 5 replicas.

Does a read replica replace backups?

No. A replica applies all changes from the primary (including DROP TABLE). Accidentally deleted data is also deleted from the replica. Read replicas are for high availability and read scaling - you still need a separate backup strategy.

Conclusion

Read replicas are the simplest and most effective way to scale databases. They significantly reduce primary load for read-heavy workloads. Manage replication lag, use the primary for critical reads, and don't neglect automatic failover configuration.

Powerful Servers for Database Replication

Minimize replication lag with Hosted Cloud's low-latency network infrastructure.

Explore Cloud Server Plans →