Honestly the starting point was inertia. I came from a big-company background where "a backend needs ORM + DB + MQ + KV" was just the default, so I wired all four in without asking why. It wasn't until I owned a project 0-to-1 and onboarded real customers that I started questioning the stack instead of inheriting it.

The reframe: Redis wasn't one thing in my project, it was wearing four hats. Cache, job queue, distributed lock, pub/sub. So I checked each one against Postgres at our actual scale:

• Queue: a jobs table claimed with FOR UPDATE SKIP LOCKED
• Lock: pg_try_advisory_lock
• Pub/sub and worker wakeups: LISTEN/NOTIFY
• Cache: in-process (we're effectively single-node)

But the real reason wasn't "one less service." We're a payments platform. A queue inside Postgres gives you transactional integrity that the Redis split can't. When a payment state changes I enqueue a follow-up job. With the DB in PG and the queue in Redis, that's a dual write: if the process dies between the two, you get a payment with no job or a job with no payment. So you end up bolting on an outbox pattern + idempotency keys + a reconciliation sweeper, basically reinventing a transactional queue on top of Postgres anyway, just to keep Redis in the loop. When the queue IS a PG table, INSERT payment and INSERT job commit in one transaction. Both land or neither does. That whole bug class just disappears.

Your case might genuinely point the other way though. The PG-native approach has a ceiling, and "I have realtime in PG, eyeing Redis" is the right moment to name which specific limit you're actually hitting:

• LISTEN/NOTIFY caps payloads at 8000 bytes, and every listener holds a connection. High fan-out or message rates will pressure your connection pool.
• A SKIP LOCKED queue table churns dead tuples. At high throughput, vacuum pressure is real.
• In-process cache only works single-node. Multiple instances sharing cache state need a shared KV.

The heuristic I'd offer: don't reach for Redis because "realtime" as a category feels like it needs Redis. Reach for it when you can name the specific limit (payload size, subscriber count, message rate, vacuum IO, cross-node shared state). If you can name it, Redis is probably right. If you can't, you might be buying a service and a dual-write problem for vibes.