Do you need Redis? PostgreSQL does queuing, locking, and pub/sub (2021)

Original Article ↗ Hacker News Discussion ↗

Scope of the Debate

  • Article’s claim: PostgreSQL can handle queuing, locking, and pub/sub, reducing the need for Redis.
  • Thread broadens this to: when is Redis actually warranted vs “just use Postgres” (or even in-process memory)?

Performance and In‑Memory vs Local DB

  • Several argue Redis’ core value is ultra‑low latency, in‑memory data structures, especially when co‑located with the app.
  • Others counter that:
    • A plain in‑process hashmap is faster still if only one process needs the data.
    • PostgreSQL on the same host with local/Unix sockets and shared buffers can be very fast; properly tuned, many workloads complete well under a millisecond.
  • Some benchmark links are criticized as flawed (e.g., no prepared statements), making direct Redis vs Postgres performance claims unclear.

Redis Use Cases Highlighted

  • Shared cache or session store for multiple web workers or hosts.
  • IPC and “shared memory” for languages or architectures without good global state.
  • Backing job systems (e.g., using lists, sorted sets, hashes as queues and indexes).
  • Use of special data structures (HyperLogLog, Bloom/Cuckoo filters, sorted sets, token buckets).
  • Persistence across app restarts without re‑implementing a small database.

PostgreSQL Capabilities and Limits

  • Queues: SELECT … FOR UPDATE SKIP LOCKED works well for modest throughput; at higher rates, table bloat and vacuum behavior become concerns. Partitioning queues by time is suggested.
  • Locks: Advisory locks are useful but have a global integer keyspace and shared namespace; some see this as awkward for application‑level locking.
  • Pub/sub: Works, but message size is limited (~8 KB); workarounds (store payloads in tables) add complexity.
  • Caching: Writes, updates, vacuuming, durability, and lack of automatic TTL make Postgres a weaker fit than Redis for high‑churn caches, though unlogged tables and tuning can mitigate this.

Operational Trade‑offs and Design Guidance

  • Many emphasize simplicity: start with Postgres; add Redis (or similar) only when proven necessary.
  • Others note Redis is easy to deploy and offloads low‑value, high‑churn data (sessions, cache) from the primary DB.
  • Concerns raised about overloading Postgres with every responsibility, impact on migrations, locking, and UI latency.
  • Consensus direction: Postgres can go very far (especially for moderate queues/locks), but Redis remains better for high‑performance caching and specialized in‑memory data structures.