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.

  • Write queries trigger smart invalidation. When an INSERT, UPDATE, or DELETE runs, PgCache determines which cached queries might be affected and invalidates them.

  • 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
  • Table-level invalidation that handles the common cases correctly
  • 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
  • Connection pooling because you probably need that too

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.

Get early access

We’re opening up early access in the coming months. Join the waitlist to be first in line and help shape the product.

Join the waitlist →

We’re excited to build something that saves teams real engineering time. Stay tuned.