There’s a moment in every developer’s journey when they step back, look at their stack, and whisper:

“Why is this so complicated?”

That moment hit me on a rainy Sunday afternoon as I stared at my architecture diagram. Redis sat there — a proud little red block — doing exactly what it was designed for: caching.

But I had a thought. A dangerous one.

“Do I really need Redis for this?”

That’s when I discovered something surprising: PostgreSQL, the relational workhorse I was already using, could do the job just fine. This is the story of how I replaced Redis with PostgreSQL — and why, in many cases, you should too.

Redis: The Legend We All Reach For

Redis is like the Swiss Army knife of backend engineering. It’s fast (in-memory), flexible (data structures!), and full-featured (TTL, pub/sub, streams). But the moment you install it, you’re also signing up for:

• Extra infrastructure to maintain

• Memory management quirks

• Deployment pipelines that just got a bit more fragile

• Security considerations for a new external port

For simple caching — think API responses, user settings, or search results — Redis is often overkill. And that’s where PostgreSQL enters the chat.

PostgreSQL: Your New Secret Cache

PostgreSQL isn’t just a database. It’s a platform. And with the right setup, it can cache like a pro.

Here’s how.

1. Create a Lightning-Fast Cache Table

Use UNLOGGED tables to skip write-ahead logging and gain speed:

CREATE UNLOGGED TABLE cache_store (
  key TEXT PRIMARY KEY,
  value JSONB NOT NULL,
  inserted_at TIMESTAMPTZ DEFAULT NOW()
);

It’s lean, it’s fast, and if the system crashes — well, it’s just cache. You’ll rebuild it.

2. Insert and Fetch with SQL Simplicity

-- Cache a new value (or update an existing one)
INSERT INTO cache_store (key, value)
VALUES ('user:123', '{"id": 123, "name": "Alice"}')
ON CONFLICT (key) DO UPDATE
SET value = EXCLUDED.value,
    inserted_at = NOW();

-- Retrieve from cache
SELECT value FROM cache_store
WHERE key = 'user:123';

Need to cache complex data? JSONB has your back. Want to index parts of your cache? PostgreSQL lets you go as deep as you want.

3. Emulate TTL Without Redis Magic

Redis has EXPIRE. PostgreSQL doesn’t. But here’s the trick:

DELETE FROM cache_store
WHERE inserted_at < NOW() - INTERVAL '30 minutes';

Schedule this with pg_cron, a built-in scheduler for PostgreSQL. If you're on managed services like RDS without pg_cron, run it in a Node.js cron job or background worker.

4. Optimize for Production

Want PostgreSQL to behave more like a caching layer?

• Use connection pooling with PgBouncer

• Avoid overloading your DB with too-frequent lookups — batch or cache in memory when possible

• Index wisely if your JSONB queries get deep or complex

Real-World Example: Goodbye, Redis

In one project, we cached user billing plans to avoid calling Stripe on every page load. Originally, we stored this in Redis. But during a refactor, we moved it into PostgreSQL with a cache_store table.

Result?

• One fewer service to deploy and monitor

• Less latency (no extra network hop)

• Fewer operational headaches

• And no noticeable performance difference for our use case

We never went back.

Should You Ditch Redis?

✅ Use PostgreSQL caching when:

• You already use PostgreSQL and want to simplify infrastructure

• Your cache is low-volume or regenerable

• You don’t need Redis-specific features like pub/sub or atomic counters

❌ Stick with Redis if:

• You need sub-millisecond performance at scale

• You’re caching session data for millions of users

• You rely on data structures like lists, sets, or streams

Final Thoughts: Fewer Tools, Fewer Headaches

Tech decisions should serve simplicity, not ego. Redis is a fantastic tool — but not always a necessary one. Sometimes, the best cache is the one you already have.

So next time you reach for Redis by default, stop. Look at your PostgreSQL instance and ask:

Can I keep it simple instead?

You might just fire Redis too.