How does Redis persistence work (RDB vs AOF)?

Question

Accepted Answer

Although Redis is in-memory, it can **persist data to disk** so data survives restarts. It offers two mechanisms — **RDB** (point-in-time snapshots) and **AOF** (append-only log of operations) — with different durability/performance trade-offs.

## RDB — point-in-time snapshots

```text
RDB takes SNAPSHOTS of the dataset at intervals, saving a compact binary file.
  ✓ Compact single-file backups; fast restarts (load the snapshot)
  ✓ Good for backups and disaster recovery; less impact on performance
  ✗ You can LOSE data since the last snapshot (e.g. last few minutes) if Redis crashes
→ Configure save points: e.g. "save after 900s if ≥1 change, 300s if ≥10 changes"
```

RDB periodically saves the whole dataset to a compact file — efficient and great for backups, but a crash loses changes made since the last snapshot.

## AOF — append-only log

```text
AOF logs EVERY write operation to a file; on restart, Redis replays the log to rebuild data.
  ✓ More DURABLE — less data loss (can fsync every second, or every write)
  ✓ The log can be rewritten/compacted to stay manageable
  ✗ Larger files; can be slower than RDB; restart (replay) can be slower
→ fsync policies: always (safest, slowest), everysec (good balance), no (fastest, riskiest)
```

AOF records every write, replaying it to rebuild data on restart — more durable (less data loss) but with larger files and potentially slower performance/restarts.

## RDB vs AOF — the trade-off

```text
RDB → better performance, compact backups, faster restart, BUT more potential data loss
AOF → better durability (minimal data loss), BUT larger files, slower

BEST PRACTICE: use BOTH together → RDB for backups + AOF for durability
  → Redis can use both; AOF for recovery, RDB for snapshots/backups
OR: pure cache use → you may DISABLE persistence entirely (data is recreatable)
```

## Why it matters

Understanding Redis persistence is important for **ensuring data durability** appropriately when Redis holds data that matters, so it's valuable knowledge for using Redis correctly.

Although Redis is primarily in-memory, the fact that it **can persist to disk** (so data survives restarts and crashes) is important to understand, along with the two mechanisms and their trade-offs. **RDB** (point-in-time snapshots) offers compact backups, fast restarts, and low performance impact, but risks **losing data since the last snapshot** on a crash — good for backups and acceptable when some data loss is tolerable. **AOF** (logging every write operation, replayed on restart) offers **better durability** (minimal data loss, configurable via fsync policies) but with larger files and potentially slower performance/restarts.

Understanding the **trade-off** (RDB for performance and compact backups vs AOF for durability) and the common **best practice of using both together** (RDB for snapshots/backups plus AOF for durability) reflects sound configuration judgment.

Also important is recognizing that for **pure caching** use (where data is recreatable from the source), persistence can be disabled entirely — Redis doesn't always need durability.

Choosing the right persistence configuration based on the use case (durability needs vs performance, or none for pure cache) is the key practical skill.

Since data durability matters when Redis holds important data (sessions, queues, primary data), and since understanding RDB, AOF, their trade-offs, and the best practices (both together, or none for caching) is necessary to configure Redis appropriately, understanding Redis persistence is valuable, practically-relevant knowledge for using Redis responsibly — ensuring the right level of durability for the data Redis holds, a topic that reflects understanding of Redis beyond simple caching.