A read replica, a Redis cache, or PgCache?

Three ways to take read load off Postgres.

Side by side

Traditional read replica Redis cache layer PgCache
Data copied 100% of the database Whatever you hand-code Only the hot working set
Freshness Replication lag Manual invalidation & TTLs Replication lag, but each connection sees its own writes
App code changes Route reads to replica Cache + invalidation logic One connection string
New system to run Another full database Redis to scale & secure A drop-in proxy
Cost model Storage + compute + IO on everything Redis infra + engineering time Predictable hourly rate, no monthly fee

What you get with PgCache

Copies only the hot data

PgCache replicates the working set your traffic actually touches, not the whole database. Fractional storage, fractional cost.

Freshness from logical replication

PgCache follows your database’s changes with logical replication and sends anything it can’t serve safely to the origin. Each connection sees its own writes.

Drop-in, no code changes

A wire-compatible Postgres proxy. Change one connection string. No Redis layer, no ORM changes, no schema migration.

Predictable monthly cost

Billed hourly on AWS Marketplace. Run it 24/7 like a read replica and it’s a flat, forecastable line item. No per-query charges, no monthly software fee.

See where your own queries land

Step 1

Check your workload

Paste a pg_stat_statements export or a Postgres log. In about a minute you see which of your queries PgCache would serve from cache.

Check your workload

Runs in your browser. Nothing is uploaded.

Step 2

Get a free workload review

30 minutes with the founders, by video or email. Bring your Fit report or your Postgres problem.

  • What PgCache would serve and save on your workload
  • If it fits, a pilot with hands-on help
Book a free review →

Free. Pick any open time on our calendar.

Run it yourself: Source on GitHub · Try it in one command

Not ready yet? Get updates by email.

No spam. Unsubscribe anytime.