Update (August 2026): PgCache is live. Everything below shipped, and it grew into a smart read replica you can try free on AWS Marketplace.

Every engineering team hits the same wall eventually: your PostgreSQL database becomes the bottleneck. Queries that were fast enough at launch start taking hundreds of milliseconds. Your p99 latencies climb. You start thinking about caching.

And then the real work begins.

The caching tax

Manual caching is surprisingly expensive. You need to:

  1. Decide what to cache. Which queries are worth caching? How do you identify hot spots without extensive profiling?

  2. Implement cache logic. Wrap your database calls, handle cache misses, serialize results. It’s boilerplate, but it’s everywhere.

  3. Invalidate correctly. This is where most teams stumble. When user 42 updates their profile, which cached queries need to be cleared? Miss one and you’re serving stale data. Over-invalidate and you’ve killed your cache hit rate.

  4. Run more infrastructure. Redis, Memcached, or something else? Now you’re managing another stateful service.

  5. Monitor and tune. Is the cache helping? What’s the hit rate? Are TTLs set correctly?

We’ve done this dance at previous companies. We’ve seen teams spend weeks building caching layers that were fragile, hard to debug, and only partially effective.

A different approach

PgCache is a PostgreSQL wire-compatible proxy. It sits between your application and your database, speaking native Postgres protocol. Your app connects to PgCache exactly like it would connect to Postgres.

Here’s what happens:

  • SELECT queries are automatically cached. PgCache identifies cacheable queries and stores their results.

  • CDC keeps your cache fresh. PgCache subscribes to PostgreSQL’s change data capture stream. When data changes, affected cache entries are updated in real-time. No manual invalidation logic required.

  • Your code doesn’t change. Same connection string (different port), same ORM, same raw SQL. PgCache is invisible to your application.

# Before: Direct connection to Postgres
DATABASE_URL=postgres://localhost:5432/myapp

# After: Connection through PgCache
DATABASE_URL=postgres://localhost:5433/myapp

What we’re building

PgCache is currently in development. Here’s what’s on our roadmap:

  • Automatic query caching with intelligent cache key generation
  • CDC-based freshness that keeps your cache updated as data changes
  • Query pattern rules for fine-grained control when you need it
  • Built-in metrics so you can see exactly what’s being cached and why

(August 2026: all four shipped.)

Who is this for?

PgCache is for teams who:

  • Are hitting database performance limits on read-heavy workloads
  • Don’t want to hand-roll caching logic throughout their codebase
  • Need something that works with their existing stack (any language, any ORM)
  • Value correctness: stale data is not acceptable

If that sounds like you, we’d love to have you try PgCache when it’s ready.

Where this went

We opened early access, shipped the MVP, and kept going. PgCache is now generally available. The fastest way to see it on your workload is the free trial on AWS Marketplace, and the mailing list is still the best way to follow along.

We’re excited to build something that saves teams real engineering time. That part hasn’t changed.