Nobody who got close to trying PgCache this year held off over speed. Mostly it was stale data, which is interesting, since lots of teams already read from a replica that lags the primary.
If that's you, here's a first step: test PgCache on the reads you send to a replica.

ALT A psql terminal window. The query SELECT replay_lag FROM pg_stat_replication returns one row: 00:00:00.284153. Below it, SQL comments read: "a replica 0.3 s behind: totally normal." "a cache fed by replication: wait, what about stale data?" "fair question. more in the post." Footer: PgCache, smart read replica for Postgres.
PgCache 0.8.0 is out!
@leonardobenedet, one of our design partners, benchmarked it the day after release. On a complex multi-tenant dashboard it served 24x the requests per second of Postgres alone at 100 tenants, and was still 1.5x ahead at 1,000 😎
We built PgCache but we've never met (yet!)
That'll change when we head to NYC in a couple weeks for Postgres Summit US/ @pgconfnyc
And, if you're in SoHo 9/30 to 10/2, and want to grab a coffee, send us DM --we'd love to connect!
Caching is a bit of a cognitive monolith
All of Read Optimization is
But we're making it better.
The goal:
You never have to think about your optimization layer again.
thereadreplica.com/news/logi…










