PgCache and PgDog

PgDog and PgCache both sit between your app and Postgres, but they solve different problems. PgDog decides which Postgres server runs each query. PgCache serves repeated reads from cache, so your database doesn't run them at all.

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

PgDog facts checked against PgDog's docs and GitHub repository on October 15, 2026.

PgCache

A caching proxy. It serves repeated reads from cache and sends everything else to your database. The cached data lives in a separate, vanilla Postgres instance, kept current through logical replication.

Takes repeated reads off your database
Picks what to cache from live traffic

PgDog

A connection pooler, load balancer and sharding proxy for Postgres. It routes each query to the right Postgres server.

What each one does

Topic	PgCache	PgDog
Solves	Repeated reads	Connection limits, read balancing and sharding
What happens to a read	Served from cache when it can be	Runs on the Postgres server PgDog picks
What it holds	Data for cached queries	Connections and routing state
Sharding	Runs on an unsharded database or per shard	Spreads data across shards

What they have in common

Both speak the Postgres protocol, so the app only changes its connection string
Both use Postgres logical replication. PgDog uses it to move data between shards, and PgCache uses it to keep its cache current.

How they fit together

PgCache in front, serving cached reads
PgDog behind it, pooling connections and spreading reads across replicas

Common questions

Does PgDog cache query results?

No. PgDog sends every query to a Postgres server, which runs it. Serving repeated reads from cache is the part PgCache adds.

Can PgCache and PgDog run together?

Yes, with PgCache in front of PgDog. PgCache reads the logical replication stream from one origin database, so it works on an unsharded database or per shard.