Redis as Cache vs As Database: When Each Fits

Redis is the multi-tool of databases. Knowing when to use which mode prevents mismatched-workload pain.

Cache mode vs DB mode

Redis can be operated as a cache or as a primary database; the modes have different operational stories. Picking the wrong mode for the workload causes the most common Redis pain.

• Cache mode. Data may be lost on restart; performance is everything; refill from the source of truth.
• DB mode. Data must persist; durability matters as much as performance; HA and backups are mandatory.
• The mismatch failure. DB mode without persistence loses data; cache mode treated as durable surprises everyone.
• The decision. Pick the mode at design time; the operational tax of the wrong mode compounds across years.

Four criteria

• 1. Acceptable data loss? Yes → cache; no → DB.
• 2. Re-fillable from source? Yes → cache; no → DB.
• 3. Sub-millisecond required? Yes → either; no → consider Postgres.
• 4. Durability + speed? DB mode + RDB+AOF.

Persistence options

Redis ships three persistence configurations. Each trades durability against write throughput and disk usage; the right pick depends on the data loss budget.

• RDB snapshots. Periodic snapshot to disk; cheap; lose every write between snapshots; fine for cache mode.
• AOF (append-only file). Write log; near-zero data loss; slower writes; the durability primitive.
• RDB plus AOF. Both enabled; best durability story; pay disk usage; the right call for DB mode.
• No persistence. Pure in-memory; restart loses everything; valid for ephemeral cache only.

Failure modes

Redis failure modes differ between cache and DB. Knowing which mode you are in determines whether the failure is recoverable or an outage.

• Cache mode failure. Cache miss on Redis-down is acceptable; app falls back to the source of truth; degraded but functional.
• DB mode failure. Redis-down equals outage; plan for HA via Sentinel or Cluster mode; backups are mandatory.
• HA setup. Sentinel for primary-replica failover; Redis Cluster for sharded HA; pick based on data size.
• Backup discipline. RDB snapshots offsite; tested restore drill quarterly; the rollback that always works.

Antipatterns

• DB mode without persistence. Data loss waiting.
• Cache mode treated as durable. Surprise data loss.
• One Redis cluster for both. Mixed concerns.

What to do this week

Three moves. (1) Apply this pattern to your most-loaded table. (2) Measure query latency / write throughput before/after. (3) Document the win and the constraint so the next refactor inherits the knowledge.