PostgreSQL Read Replicas: Scale Reads Safely

As a web application grows, the database is often the first part to feel the strain. Dashboards, reports, search pages and exports compete with the inserts and updates that keep the business running. PostgreSQL read replicas offer one way to relieve that pressure: one or more standby servers receive a continuous copy of changes from the primary and can answer read-only queries, leaving the primary free to handle writes. Replicas are not a cure-all, though. They introduce replication delay, routing decisions and new failure modes. This guide explains how PostgreSQL read replicas work, which workloads suit them, how to handle stale reads and what to monitor.

How PostgreSQL read replicas work

PostgreSQL records every change in its write-ahead log (WAL). A standby server can receive that log from the primary and replay it, keeping a copy of the database that is close to current. The PostgreSQL documentation uses the term hot standby for the ability to connect to a server and run read-only queries while it is in standby mode (PostgreSQL: Hot Standby). That is what makes a standby usable as a read replica.

Changes usually arrive through streaming replication. According to the PostgreSQL documentation, streaming replication is asynchronous by default, in which case there is a small delay between committing a transaction on the primary and the change becoming visible on the standby (PostgreSQL: Log-Shipping Standby Servers). The same documentation notes that synchronous replication is also available, at the cost of waiting for confirmation from a standby before a commit completes.

Which workloads suit read replicas

Replicas help most when read traffic is heavy and can tolerate slightly old data:

• Reporting and analytics queries that scan large amounts of data
• Dashboards that refresh regularly
• Search and listing pages
• Data exports and scheduled extracts
• Read-only APIs used by internal tools or other systems

They help less when the bottleneck is write volume, lock contention or a few badly written queries. Replicas copy every write, so they do not reduce write load on the primary.

Fix queries before adding servers

Before adding replicas, check whether the problem can be solved more cheaply:

• Find the slowest and most frequent queries
• Add or adjust indexes where they clearly help
• Remove unnecessary queries, such as repeated lookups in loops
• Use connection pooling so the database is not overwhelmed by connections
• Cache results that change rarely

Our guide to PostgreSQL connection pooling explains how pooling reduces connection overhead, which is often a quicker win than a replica.

Plan for replication delay

Because asynchronous replicas trail the primary, a user can write data and then read an older version from a replica. Common examples include saving a profile and seeing the old values, or creating an order that does not yet appear in the list. Options to handle this include:

• Read your own writes: send reads that follow a user's write to the primary for a short period
• Route by freshness need: keep critical reads, such as account balances or stock levels, on the primary
• Show status clearly: tell users when data is still updating rather than showing a confusing result
• Check lag: avoid sending traffic to a replica whose delay exceeds an agreed threshold

Decide for each type of query how fresh the data must be.

Route queries deliberately

Applications need a way to decide which server handles each query. Approaches include:

• Separate connection settings for writes and reads in the application code
• A database proxy or pooler that sends read-only traffic to replicas
• Framework features that support read and write database configurations

Keep routing rules simple and visible. A hidden rule that sends some writes to a read-only replica will fail with an error; a rule that sends freshness-critical reads to a lagging replica will fail silently, which is worse.

Worked example: query routing plan

The table below is a hypothetical routing plan for a business web application. It shows how to classify queries, not a recommended configuration.

Query typeFreshness needRoute toNotesLogin and session checksMust be currentPrimarySecurity-sensitiveOrder creation and paymentMust be currentPrimaryWritesOrder list right after checkoutMust reflect the user's writePrimary for a short periodRead your own writesProduct catalogue pagesA short delay is acceptableReplicaHigh volumeMonthly sales reportDelay is acceptableReplicaLong-running scansAdmin data exportDelay is acceptableReplica, off-peakLarge result sets

Watch for query conflicts

Long-running queries on a standby can conflict with changes being replayed from the primary. The PostgreSQL documentation has a section on handling query conflicts on hot standby servers, and the settings involved trade replay delay against cancelled queries. If reports on a replica are cancelled unexpectedly, or replicas fall further behind during heavy reporting, review these settings with the documentation for your version.

Understand what replicas do not protect against

A replica copies changes, including mistakes. If someone deletes the wrong rows on the primary, the delete is replayed on the replica too. Replicas are not backups. Keep regular backups and test restores separately.

Replicas also do not automatically provide high availability. Promoting a standby to become the new primary requires a failover process, and with asynchronous replication, recent transactions that had not reached the standby may be lost. The documentation notes that asynchronous log shipping leaves a window for data loss if the primary suffers a catastrophic failure. Our guide to high availability architecture covers failover design in more depth.

Monitor the right signals

Track:

• Replication lag on each replica, in time or bytes
• Replica CPU, memory and disk usage
• Query volume and latency on primary and replicas
• Cancelled queries on replicas
• Connection counts on each server

Alert when lag rises above the level your routing rules assume.

Test before relying on replicas

Test with realistic data and traffic. Check how lag behaves under peak write load, what happens to the application if a replica becomes unavailable, and whether routing falls back to the primary safely. Practise promoting a standby in a non-production environment so the steps are familiar.

Consider managed services carefully

Many cloud database services offer managed read replicas. They simplify setup and monitoring, but the same principles apply: replication delay, routing, query conflicts and failover still need planning. Read the provider's documentation for how lag, promotion and maintenance are handled.

Frequently Asked Questions

What is a PostgreSQL read replica?

It is a standby server that receives changes from the primary through the write-ahead log and answers read-only queries, reducing read load on the primary.

Do PostgreSQL read replicas reduce write load?

No. Every write is still made on the primary and replayed on each replica, so replicas help with read traffic, not write volume.

Why might a replica return old data?

Streaming replication is asynchronous by default, so there is a small delay before committed changes appear on the standby.

Are read replicas a backup?

No. Mistakes such as accidental deletes are replicated too, so separate backups and tested restores are still needed.

Scale database reads with confidence

We review query performance, design replica routing and set up monitoring for PostgreSQL applications. See our custom app development services, or talk to us about PostgreSQL read replicas.

About the Author

Manav Sharma is the founder of Insyrge and a CRM solutions architect. He works across Zoho, Salesforce, HubSpot, Odoo and more, designing the CRM setups, integrations and automations that keep sales and operations teams working from the same data.