Redis vs Postgres for Cache

When each.

Overview

Redis is purpose-built for cache; Postgres can serve as one when you do not want to add another database. The choice depends on whether the operational cost of a second datastore is worth the latency, eviction, and data-structure features Redis offers. Both are reasonable; one is just more reasonable than the other for most workloads.

• Redis dedicated cache. Sub-millisecond reads, native TTL/eviction, rich data structures (lists, sets, sorted sets), pub/sub, atomic operations.
• Postgres as cache (UNLOGGED tables, materialised views). One fewer database to operate, ACID semantics included, but no native eviction and higher per-read latency.
• Operational fit. Redis wins for hot-path caches with strict latency requirements; Postgres wins when the workload tolerates ms-scale reads and the operational budget cannot absorb another datastore.
• Per-data decision and total cost of ownership. Adding Redis adds an on-call surface and a backup strategy; reusing Postgres pays in latency.

The approach

Match the choice to the latency floor and the operational budget. Cache use cases vary widely; one answer rarely fits all of them.

• Latency budget per cache use case. Sub-millisecond reads need Redis; tens-of-milliseconds tolerance opens Postgres.
• Eviction strategy. Redis handles TTL and LRU/LFU natively; Postgres requires application-side management.
• Operational footprint check. Honestly count whether the team can absorb another datastore on-call; if not, lean Postgres.
• Document the choice and the trigger to revisit. Capture rationale per cache; the answer for session storage is rarely the same as for product-page caching.

Why this compounds

The right cache choice keeps paying back: latency stays predictable as traffic grows, evictions happen automatically, and the data-store inventory stays small enough to operate well.

• Operational fit. Matching cache to workload prevents the slow drift toward "one more datastore that nobody quite owns."
• Cost efficiency. Skipping Redis where Postgres suffices saves licence, infra, and on-call cost.
• Engineering velocity. Fewer datastores means fewer connection pools, fewer client libraries, fewer failure modes.
• Decision trail for the next cache. Each documented choice teaches the next team which questions to ask, not which datastore to default to.