PgCache vs read replicas

Read replicas and PgCache both take read load off your database, and both stay current through Postgres replication. A read replica serves any read from the whole database. PgCache serves only the reads your app repeats, from just the data those reads need.

See which of your own queries PgCache would serve: check your workload or open a sample report.

Replica facts checked against the PostgreSQL, Amazon RDS and Aurora docs on October 15, 2026.

PgCache

A caching proxy. It stores the data for your repeated reads in a separate, vanilla Postgres instance and keeps that data current through logical replication.

Holds the hot data, not the whole database
One connection string for reads and writes
Each connection reads its own writes

Read replica

A second Postgres server that follows your primary and answers read-only queries.

Where they differ

Topic	PgCache	Read replica
Data it serves from	Just the data your cached reads need	The whole database
Reads it handles	Cached reads. The rest go to your database.	Any read-only query
App changes	One connection string	Reads go to the replica, writes to the primary
Freshness	Within typical logical replication lag. Each connection always sees its own writes.	Within replication lag. A read right after the app’s own write can miss it.
Size	Sized to the data your traffic reads	A full database instance

Which one fits

Choose PgCache when

The same reads run all day
A small part of the data serves most of the reads
You’re adding replicas only for read capacity

Choose a read replica when

You need a standby to fail over to
You run heavy one-off reads, like analytics or exports
You’re on Postgres 15 or earlier

Why PgCache can be smaller than a replica

A replica holds the whole database because any read can land on it. PgCache serves only the reads it has cached, so it only needs the data behind them. On most applications, a small part of the data serves most of the reads. That’s the idea behind what we call a smart read replica. The replica cost page estimates the savings for your setup.

What they have in common

Both take read load off your database
Both stay current through Postgres replication
Writes still go to your primary database in both setups

Using them together

A replica for failover and heavy one-off queries
PgCache for the reads your app repeats

Common questions

Is PgCache a read replica?

It works like one: it stays current through Postgres replication and serves reads. The difference is that PgCache keeps just the data your cached queries need and sends everything else, writes included, to your database. We call it a smart read replica.

Can PgCache replace my read replicas?

For the reads your app repeats, yes. Keep a replica if you need a failover target or run heavy one-off queries. The Fit Analyzer shows how much of your workload PgCache would serve.