As an application grows, the database can become one of the biggest performance bottlenecks.
A common pattern looks like this:
Users
↓
Application
↓
PostgreSQL
At first, this architecture works well. But as traffic increases, the number of database queries also grows.
Many applications perform significantly more read operations than write operations.
For example:
10,000 database operations
↓
8,000 reads
2,000 writes
In this situation, sending every query to a single PostgreSQL server can create unnecessary pressure on the primary database.
A common solution is PostgreSQL read replicas.
Read replicas allow PostgreSQL data to be replicated from a primary server to one or more additional PostgreSQL servers. Applications can then send appropriate read queries to the replicas while writes continue to go to the primary.
The architecture becomes:
┌── Read Replica 1
│
Application ────────┼── Read Replica 2
│
└── Read Replica 3
↑
│
Replication
│
Primary
In this guide, we’ll explain how PostgreSQL read replicas work, why they’re useful, how replication affects consistency, how applications route reads and writes, and what you need to consider before using them in production.
What Is a PostgreSQL Read Replica?
A read replica is a PostgreSQL server that receives replicated changes from a primary PostgreSQL server.
The primary database handles writes:
INSERT
UPDATE
DELETE
The replicas can handle appropriate read workloads:
SELECT
Conceptually:
Primary
│
│ Replication
↓
Replica 1
Replica 2
Replica 3
The replicas maintain copies of the primary’s data and can be used to serve read traffic.
Primary vs Read Replica
The primary database is generally responsible for:
INSERT
UPDATE
DELETE
DDL
Read replicas are generally used for:
SELECT
A simple architecture is:
Application
/ \
/ \
Writes Reads
↓ ↓
Primary Read Replicas
This separates write and read workloads.
Why Use Read Replicas?
The main reason is to scale read-heavy workloads.
Suppose your application has:
1 Primary
3 Read Replicas
Instead of:
10,000 reads → Primary
2,000 writes → Primary
you can distribute reads:
3,333 reads → Replica 1
3,333 reads → Replica 2
3,334 reads → Replica 3
2,000 writes → Primary
The exact distribution depends on your load-balancing strategy, but the basic idea is to reduce read pressure on the primary.
Read-Heavy Applications
Read replicas are particularly useful when an application performs many more reads than writes.
Examples include:
- E-commerce product catalogs
- News websites
- Social media feeds
- Analytics dashboards
- Search-heavy applications
- Content platforms
- SaaS applications
- Reporting systems
For example:
Product page
↓
SELECT product
SELECT reviews
SELECT recommendations
SELECT inventory
A popular product page can generate many database reads.
Read replicas can help distribute that workload.
How PostgreSQL Replication Works
PostgreSQL commonly uses WAL-based replication.
WAL stands for:
Write-Ahead Logging
When PostgreSQL changes data, it records those changes in its WAL.
The primary can send WAL information to replicas.
Conceptually:
Application
↓
Primary PostgreSQL
↓
WAL
↓
Replication Stream
↓
Read Replica
The replica replays the replicated changes to keep its database state synchronized with the primary.
Streaming Replication
PostgreSQL supports streaming replication.
The primary streams WAL records to a standby server.
Conceptually:
Primary
│
│ WAL stream
↓
Standby
The standby receives and replays the WAL records.
This allows the replica to stay relatively close to the primary.
Physical Replication
PostgreSQL physical replication replicates changes at the database storage/WAL level.
A physical standby maintains a copy of the primary’s database cluster.
This is different from logical replication, which works at a higher logical level.
Physical replication is commonly used for:
- Read replicas
- High availability
- Disaster recovery
- Standby servers
Logical Replication
PostgreSQL also supports logical replication.
Logical replication can replicate changes to selected tables or sets of data rather than replicating the entire physical database cluster in the same way as physical streaming replication.
Conceptually:
Publisher
↓
Logical Changes
↓
Subscriber
Logical replication can be useful when you need more selective or flexible replication architectures.
Read Replicas Are Usually Read-Only
A physical standby/read replica is generally not used as an independent writable copy while it is acting as a standby.
For example:
SELECT *
FROM products;
is appropriate for a read replica.
But:
UPDATE products
SET price = 100;
should go to the primary in a typical primary/replica architecture.
The application therefore needs to know where each operation belongs.
Routing Reads and Writes
A common application architecture is:
Application
/ \
↓ ↓
Writes Reads
↓ ↓
Primary Replica Pool
/ | \
↓ ↓ ↓
R1 R2 R3
The application can maintain separate database connections or pools.
For example:
writePool → Primary
readPool → Read Replica
Node.js Example
Suppose you’re using Node.js with PostgreSQL.
You might have:
const { Pool } = require('pg');
const writePool = new Pool({
host: process.env.PRIMARY_DB_HOST,
database: process.env.DB_NAME,
user: process.env.DB_USER,
password: process.env.DB_PASSWORD
});
const readPool = new Pool({
host: process.env.REPLICA_DB_HOST,
database: process.env.DB_NAME,
user: process.env.DB_USER,
password: process.env.DB_PASSWORD
});
Writes can use:
await writePool.query(
'INSERT INTO users (name) VALUES ($1)',[name]
);
Reads can use:
const result = await readPool.query(
'SELECT * FROM users WHERE id = $1',
[userId]
);
This creates a basic read/write split.
Read/Write Splitting
Read/write splitting means routing different database operations to different servers.
INSERT
UPDATE
DELETE
↓
Primary
SELECT
↓
Replica
A more advanced architecture might look like:
API
↓
Database Router
/ \
/ \
Write Read
↓ ↓
Primary Replica Pool
/ | \
R1 R2 R3
Connection Pools for Replicas
If you have multiple replicas, you can maintain a pool or connection endpoint for the read tier.
For example:
Application
↓
Read Pool
↓
Replica endpoint
↓
R1 / R2 / R3
The infrastructure can distribute connections among replicas.
This is often preferable to hard-coding individual replica selection throughout application code.
Read Replica Load Balancing
Suppose you have three replicas:
Replica 1
Replica 2
Replica 3
Read traffic can be distributed between them.
Possible strategies include:
Round robin
Least connections
Load-based routing
Connection-level balancing
Application-level routing
The exact strategy depends on the infrastructure you use.
Read Replicas and Replication Lag
One of the most important concepts is replication lag.
A replica doesn’t necessarily receive and apply every change at exactly the same moment as the primary.
For example:
Primary
User created at 10:00:00
↓
Replication
↓
Replica receives change at 10:00:00.200
For a short period, the replica may not contain the newest data.
This is called replication lag.
Why Replication Lag Matters
Consider this sequence:
1. User creates an order
2. Application writes to primary
3. Application immediately reads orders from replica
If the replica hasn’t received the new WAL changes yet:
Primary → Contains order
Replica → Doesn't contain order yet
The user may see stale information.
This is one of the most important trade-offs of read replicas.
Example of Stale Reads
Suppose:
INSERT INTO orders (user_id, total)
VALUES (10, 500);
The write succeeds on the primary.
Immediately afterward:
SELECT *
FROM orders
WHERE user_id = 10;
If this query goes to a lagging replica, the newly inserted order might not appear yet.
Therefore:
Read replicas can introduce eventual consistency for reads routed to replicas.
Strong vs Eventual Consistency
A primary database can provide the latest committed state for its own reads.
With asynchronous replication:
Primary
→ Latest state
Replica
→ Potentially slightly older state
This means the application needs to understand where stale data is acceptable.
When Stale Reads Are Acceptable
Replica reads are often fine for:
Product listings
Public content
News feeds
Analytics
Search results
Recommendation data
Reporting
Dashboards
A delay of a fraction of a second may not matter.
When Stale Reads Are Dangerous
Be careful with replicas for:
Payment confirmation
Account balance
Inventory after purchase
Order confirmation
Authentication-sensitive state
Immediately updated settings
Critical transactional workflows
For these operations, reading from the primary may be safer when the latest state is required.
Read-After-Write Consistency
A common application requirement is:
Write
↓
Immediately read
↓
Must see the new data
For example:
User updates profile
↓
Save to primary
↓
Fetch profile
↓
Must show new profile
If the second query goes to a lagging replica, the application could show the old value.
A common strategy is:
After important write
↓
Temporarily read from primary
This is sometimes called read-your-writes behavior.
Primary for Critical Reads
A simple strategy is:
Critical read
↓
Primary
Normal read
↓
Replica
For example:
Payment status → Primary
Product catalog → Replica
This lets you benefit from replicas without sacrificing consistency where it matters.
Replicas and Analytics
Large analytical queries can consume significant database resources.
For example:
SELECT
customer_id,
SUM(amount)
FROM orders
GROUP BY customer_id;
Running large reporting queries on the primary may affect production workloads.
A replica can sometimes be used for reporting:
Production writes
↓
Primary
↓
Replica
↓
Analytics queries
This isolates some read-heavy reporting work from the primary.
However, analytics workloads may still be better suited to a dedicated analytical system at larger scales.
Read Replicas vs Caching
Read replicas and caching solve different problems.
Read Replica
Application
↓
Replica
↓
PostgreSQL
The query still reaches PostgreSQL.
Cache
Application
↓
Cache
↓
Database only on cache miss
A cache can avoid database queries altogether.
For frequently requested data, caching may provide a larger performance improvement than simply adding replicas.
Read Replicas + Redis
A scalable architecture might use both:
Application
/ | \
/ | \
Cache Reads Writes
↓ ↓ ↓
Redis Replica Primary
For example:
Frequently accessed data
→ Redis
Normal reads
→ PostgreSQL replica
Writes
→ PostgreSQL primary
This combination can handle substantial workloads when designed correctly.
Read Replicas Do Not Automatically Make Queries Faster
Suppose a query takes:
5 seconds
because it lacks an appropriate index.
Moving it to a replica doesn’t automatically make it:
0.1 seconds
The query is still expensive.
You may need:
Indexes
Query optimization
Better schema design
Partitioning
Caching
Query rewriting
Read replicas primarily help distribute workload, not magically optimize SQL.
Indexes Still Matter
A replica receives replicated database changes, including the database structures required for the replicated workload.
You should still design appropriate indexes on the primary.
For example:
CREATE INDEX idx_orders_user_id
ON orders(user_id);
Then:
SELECT *
FROM orders
WHERE user_id = 100;
can use an appropriate index when the query planner determines it is beneficial.
Read Replica Scaling
Suppose one primary handles:
10,000 reads
2,000 writes
You add one replica:
Primary
→ 5,000 reads
→ 2,000 writes
Replica
→ 5,000 reads
Add another:
Primary
→ 3,333 reads
→ 2,000 writes
Replica 1
→ 3,333 reads
Replica 2
→ 3,334 reads
The exact distribution depends on traffic and routing, but the architecture allows read capacity to grow horizontally.
Adding More Replicas
If read demand increases:
Primary
↓
Replica 1
Replica 2
Replica 3
you can potentially add:
Replica 4
Replica 5
and distribute additional read traffic.
This is one of the major benefits of read replicas.
Read Replicas and High Availability
Read replicas can also play a role in high availability.
If the primary fails, an appropriate standby can potentially be promoted to become the new primary.
Conceptually:
Primary
│
↓
Standby / Replica
│
Failover
↓
New Primary
However:
A read replica is not automatically a complete high-availability solution.
Production HA requires additional considerations such as:
- Failover automation
- Health checks
- Application reconnection
- Service discovery
- Monitoring
- Backup strategy
- Recovery procedures
- Replication mode
Read Replica vs Backup
A replica is not a replacement for backups.
Replication generally copies changes, including destructive changes.
For example:
Primary
DELETE data
↓
Replica
DELETE replicated data
If data is accidentally deleted, the replica may also receive that deletion.
Backups provide a different recovery mechanism.
A robust PostgreSQL strategy often includes:
Primary
+
Read Replicas
+
Backups
+
Point-in-Time Recovery
Synchronous vs Asynchronous Replication
PostgreSQL supports different replication configurations.
Asynchronous Replication
The primary doesn’t necessarily wait for a replica to confirm that WAL has been safely received and applied before completing the transaction.
Conceptually:
Write
↓
Primary commits
↓
Replica catches up
This can provide good performance but allows some replication lag.
Synchronous Replication
The primary can be configured to wait for confirmation from a synchronous standby according to the configured synchronous replication settings.
Conceptually:
Write
↓
Primary + synchronous standby
↓
Commit
This can improve durability/consistency guarantees but may add latency and availability trade-offs.
Asynchronous Replication Is Common for Read Scaling
For many read-scaling architectures:
Primary
↓
Asynchronous replicas
is a practical choice.
The goal is generally:
Primary
→ Handle writes
Replicas
→ Scale reads
Small amounts of replication lag may be acceptable for non-critical reads.
Monitoring Replication Lag
In production, monitor replication health.
Useful metrics include:
Replication lag
WAL generation rate
Replica replay position
Replica availability
Replication errors
Query latency
Connection count
CPU usage
Disk I/O
If replication lag suddenly increases:
Primary workload ↑
↓
WAL generation ↑
↓
Replica falls behind
↓
Stale reads increase
This can become an application-level problem.
What Causes Replication Lag?
Common causes include:
- Heavy write workload
- Slow network
- Replica CPU saturation
- Slow disk I/O
- Long-running queries
- Large transactions
- Replica resource constraints
- WAL generation exceeding replica replay capacity
For example:
Primary writes
↓
Very high WAL generation
↓
Replica cannot replay quickly enough
↓
Replication lag
Long-Running Queries on Replicas
A read replica may be used for reporting queries.
But a very long-running query can sometimes interfere with the replica’s ability to keep up with replay, depending on the query and PostgreSQL configuration.
For example:
Replica
├── Long analytics query
└── WAL replay
Careful workload management is important.
Read Replicas and Connection Pooling
Connection pooling becomes important when applications have many replicas.
For example:
Application
├── Write Pool → Primary
│
└── Read Pool → Replica Endpoint
If there are multiple application instances, each instance may have its own pools.
Remember:
Application instances
×
Pool size
=
Potential connections
The total connection budget still matters.
Read Replicas With Multiple Application Servers
Suppose:
5 application servers
Each has:
Read pool = 10
The potential number of read connections is:
5 × 10 = 50
If you scale to 20 application servers:
20 × 10 = 200
This can significantly increase database connection pressure.
Connection pooling must therefore be designed together with application scaling.
Read Replica Routing Strategies
There are several ways to route read queries.
Application-Level Routing
The application decides:
SELECT → Replica
INSERT → Primary
This is straightforward but requires routing logic in the application.
Database Proxy
A proxy can sit between the application and database servers:
Application
↓
Database Proxy
/ \
Primary Replicas
The proxy can provide routing and load balancing depending on the product and configuration.
Managed Database Endpoints
Cloud database providers may provide separate endpoints for:
Primary
Read replicas
Read-only endpoint
The application can use those endpoints rather than manually managing individual replica addresses.
Read Replicas and ORMs
ORMs can simplify database access but read/write splitting requires correct configuration.
For example:
ORM
├── Write connection
└── Read connection
Some frameworks provide built-in support for read/write database configurations.
Others require custom routing.
Always verify that transactions and consistency-sensitive queries are routed correctly.
Read Replicas and Transactions
Transactions should generally use a consistent database connection/session.
For example:
BEGIN
↓
UPDATE primary
↓
SELECT primary
↓
COMMIT
You don’t want a transaction to accidentally switch between a primary and a lagging replica.
For transactional workflows, use the appropriate primary connection unless your architecture explicitly supports another consistency model.
Read Replicas and Search
Read replicas can be useful for search queries that still use PostgreSQL.
For example:
SELECT id, name
FROM products
WHERE name ILIKE '%laptop%';
However, if search becomes a major workload, a dedicated search engine may be more appropriate.
Read replicas are one scaling tool, not a solution for every workload.
Read Replicas for Reporting
A common architecture is:
Production
↓
Primary
↓
Read Replica
↓
Reporting
This allows reporting queries to be separated from normal production traffic.
For very large analytics workloads, you may eventually move data into a dedicated warehouse or analytical database.
Read Replicas and Pagination
Suppose your application uses:
SELECT *
FROM products
ORDER BY created_at DESC
LIMIT 50;
A replica can serve this query.
However, if data changes rapidly, users may see slightly different results between requests because the replica may lag or because the underlying data is changing.
For high-consistency pagination, consider whether the query should go to the primary or use an appropriate consistency strategy.
Read Replicas and Caching Together
A mature architecture might look like:
Users
↓
Application
/ | \
/ | \
Cache Reads Writes
↓ ↓ ↓
Redis Replicas Primary
↓
WAL
↓
Replicas
This architecture can separate:
Very hot data
→ Cache
Normal reads
→ Replicas
Writes
→ Primary
When Should You Add a Read Replica?
Consider adding a read replica when:
✔ Read traffic is significantly increasing
✔ Primary CPU is high because of reads
✔ Reporting queries affect production traffic
✔ You need additional read capacity
✔ Caching alone isn't sufficient
✔ You want a standby for HA/DR purposes
Don’t add replicas simply because your application has many users.
First measure where the bottleneck actually is.
Signs You May Need Read Scaling
Monitor your primary database.
Potential warning signs include:
High CPU
High read I/O
Increasing query latency
Growing SELECT workload
Reporting queries affecting production
Connection pressure
Slow response times during traffic spikes
For example:
Traffic ↑
↓
SELECT queries ↑
↓
Primary CPU ↑
↓
Query latency ↑
A read replica can help by moving suitable read workloads away from the primary.
When Read Replicas May Not Help
Read replicas may not solve the problem if:
Writes are the bottleneck
Queries are poorly optimized
Indexes are missing
Transactions are too long
Connection management is inefficient
Application logic creates excessive queries
The workload requires strong read-after-write consistency
In these cases, investigate the underlying bottleneck first.
Common Mistakes
Mistake 1: Sending Every SELECT to Replicas
Not every read should necessarily go to a replica.
Consistency-sensitive reads may need the primary.
Mistake 2: Ignoring Replication Lag
Always understand how stale replica data can become.
Mistake 3: Treating Replicas as Backups
Replication does not replace backups.
Mistake 4: Adding Replicas Before Optimizing Queries
A poorly indexed query may remain expensive on every replica.
Mistake 5: Ignoring Connection Counts
Every application instance can create its own connection pool.
Mistake 6: Using Replicas for Writes
A typical read replica is intended for read traffic, not ordinary application writes.
Mistake 7: Forgetting Failover
If a replica is also intended for HA, plan how it will be promoted and how applications will reconnect.
Best Practices
1. Measure Before Scaling
Use PostgreSQL monitoring and query analysis to identify the actual bottleneck.
2. Optimize Queries First
Use:
EXPLAIN ANALYZE
to investigate slow queries.
3. Use Appropriate Indexes
Indexes can often provide a much larger improvement than adding another database server.
4. Route Only Suitable Reads
Send consistency-sensitive operations to the primary.
5. Monitor Replication Lag
Stale reads can become a user-facing problem.
6. Use Connection Pooling
Avoid opening a new database connection for every request.
7. Keep Backups Separate
Maintain backups even when replicas exist.
8. Plan for Failover
If replicas are part of your HA strategy, test the failover process.
9. Consider Caching
Frequently accessed data may be better served from a cache.
10. Reevaluate Architecture at Larger Scale
If analytics or search becomes dominant, consider specialized systems instead of continuously adding PostgreSQL replicas.
Example: E-Commerce Architecture
Imagine an online store.
The application receives:
Product browsing
→ Millions of reads
Order creation
→ Thousands of writes
A suitable architecture could be:
Users
↓
Application
/ \
/ \
Reads Writes
↓ ↓
Read Replica Primary
/ \
↓ ↓
Replica 1 Replica 2
Product browsing can use replicas:
SELECT *
FROM products
WHERE category_id = 10;
Order creation goes to the primary:
INSERT INTO orders (...)
VALUES (...);
Payment and inventory-sensitive reads may also use the primary when the latest committed state is required.
Example: Analytics Dashboard
Suppose a dashboard runs:
SELECT
DATE_TRUNC('day', created_at),
COUNT(*),
SUM(amount)
FROM orders
GROUP BY DATE_TRUNC('day', created_at);
If this query scans millions of rows, running it repeatedly on the primary could affect production traffic.
A replica can sometimes be used:
Production traffic
↓
Primary
Analytics
↓
Read Replica
For very large analytics workloads, however, a dedicated analytical system may be a better long-term solution.
Simple Architecture to Remember
The core pattern is:
┌───────────────┐
│ Application │
└───────┬───────┘
│
┌────────────┴────────────┐
↓ ↓
Writes Reads
↓ ↓
┌─────────┐ ┌────────────┐
│ Primary │─── WAL ───→ │ Replica 1 │
└─────────┘ └────────────┘
│
┌───────┴───────┐
↓ ↓
Replica 2 Replica 3
The primary remains the source for writes, while replicas provide additional read capacity.
Read Replicas vs Vertical Scaling
Before adding replicas, you can also scale the primary vertically.
For example:
More CPU
More RAM
Faster storage
Better I/O
This can be effective.
But eventually, a single machine has physical limits.
Read replicas allow read capacity to be distributed across multiple machines.
Read Replicas vs Sharding
These approaches solve different problems.
Read Replicas
One logical dataset
↓
Multiple copies
↓
Scale reads
Sharding
Dataset
↓
Partition across servers
Read replicas are generally simpler when the main problem is read throughput.
Sharding is much more complex and is typically considered when a single PostgreSQL instance cannot handle the overall workload or data requirements.
Read Replicas and Data Consistency
Before implementing read replicas, define your application’s consistency requirements.
Ask:
Can this page show slightly stale data?
Can this dashboard be a few seconds behind?
Must the user immediately see their update?
Must inventory always be current?
Must payment status be current?
These answers determine which queries can safely use replicas.
Final Thoughts
PostgreSQL read replicas are a powerful way to scale applications that perform a large number of read operations.
The basic architecture is:
Writes
↓
Primary
Reads
↓
Read Replicas
This allows read traffic to be distributed across multiple PostgreSQL servers.
However, read replicas introduce important considerations:
Replication lag
Read-after-write consistency
Connection management
Failover
Monitoring
Routing
Backups
Query optimization
The most important thing to remember is:
Read replicas increase read capacity by distributing database reads, but they don’t replace query optimization, caching, backups, or proper high-availability planning.
A good scaling strategy often evolves like this:
1. Optimize SQL
↓
2. Add indexes
↓
3. Use connection pooling
↓
4. Add caching
↓
5. Add read replicas
↓
6. Consider specialized systems
when the workload requires them
For read-heavy PostgreSQL applications, read replicas can provide a significant increase in capacity while allowing the primary database to focus more heavily on writes and transactional workloads.
