Readyset and PgCache are both caching proxies that sit between your app and your database. The main difference is how cached results stay fresh. Readyset has two kinds of cache: its default kind refreshes on a timer, and its other kind is kept current through replication. PgCache has one kind: every cached query is picked automatically and kept current through replication.
See which of your own queries PgCache would serve: check your workload or open a sample report.
Readyset facts checked against Readyset's docs and blog on .
A caching proxy for Postgres. It picks what to cache from live traffic, stores the data in a separate, vanilla Postgres instance, and keeps that data current through logical replication.
A caching proxy for Postgres and MySQL. Its default caches refresh on a timer. Its other kind of cache is kept current through replication.
| Topic | PgCache | Readyset |
|---|---|---|
| Kinds of cache | One, kept current through replication | Two. Timer-based by default, or kept current through replication. |
| Choosing what to cache | Automatic, from live traffic | Declared per query, or picked automatically |
| What it stores | Just the data your cached queries need | Caches kept current through replication start from a copy of your tables |
| Query variations | A cached query also serves narrower ones it covers | Each cache serves one query shape |
| Databases | Postgres 16 and later | Postgres 13 and later, and MySQL |
Sometimes a new query only needs rows that a cached query already holds. In that case PgCache serves the new query from cache, without sending it to your database. A cached WHERE value > 50 covers WHERE value > 100 and WHERE value = 100. A cached WHERE tenant_id = 1 covers WHERE tenant_id = 1 AND status = 'active'. The docs list every case.
No. PgCache caches every query it can serve safely, from the first time it sees it. You can limit caching to certain tables.
No. PgCache is built on Postgres logical replication and supports Postgres 16, 17 and 18.
If something here is out of date, please write to [email protected].
Step 1
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.
No export handy? See a sample report
Runs in your browser. Nothing is uploaded.
Step 2
30 minutes with the founders, by video or email. Bring your Fit report or your Postgres problem.
Prefer email? [email protected]
Already curious? Request a pilot
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.