Redis persistence determines what happens to in-memory data when the process or host restarts. The two primary persistence models are RDB snapshots and AOF (Append Only File). They can be used separately, together, or not at all depending on the workload.
For production teams, the right question is not “which persistence mode is best?” It is how much data can be lost, how quickly the service must recover, and whether Redis-compatible state is reconstructable from another source.
This guide owns Redis persistence and recovery trade-offs. For hosting and operational ownership, use Redis Hosting: Managed Valkey vs Self-Hosted Redis. For cache, queue, and session role design, use Redis Cache Strategy for SaaS Apps.
RDB and AOF protect different recovery goals
| Mode | How it works | Main strength | Main trade-off |
|---|---|---|---|
| RDB | Periodic point-in-time snapshots | Compact files, fast restart/backup handling | Changes after the last snapshot can be lost |
| AOF | Logs write operations | Finer-grained durability | Larger files and replay/rewrite overhead |
| RDB + AOF | Uses both | Combines snapshot and write-log recovery options | More storage and operational complexity |
| No persistence | Memory only | Lowest persistence overhead | Data disappears after restart |
Redis documentation explicitly supports all four patterns.
The correct choice depends on whether the dataset is disposable cache, rebuildable application state, sessions, queue state, or something that would cause unacceptable customer impact if lost.
RDB snapshots trade recovery point for simplicity
RDB saves a point-in-time representation of the dataset according to configured save rules.
A simplified timeline is:
12:00 snapshot 12:01 writes 12:02 writes 12:03 process failure
If the last valid snapshot is 12:00, the writes after that point may be lost.
RDB is attractive when:
- the data can tolerate a recovery gap;
- fast restart from a compact snapshot matters;
- the dataset is mostly cache or reconstructable state;
- backups need a portable snapshot artifact;
- write-log durability is unnecessary.
It is a poor fit when losing the latest minutes of queue, session, or coordination state would violate the workload's recovery requirements.
AOF reduces the recovery gap by recording writes
AOF records write operations that can be replayed after restart.
Redis supports different fsync policies that trade durability against write overhead. A stricter policy reduces the amount of acknowledged work that can be lost during a crash but increases persistence I/O.
AOF also needs periodic rewrite/compaction because an append-only history can grow much larger than the current dataset.
Use AOF when:
- recent write loss must be minimized;
- the dataset cannot simply fall back to the last periodic snapshot;
- queue/session state has stronger durability requirements;
- the storage layer can sustain the persistence workload;
- the team can monitor AOF rewrite and disk growth.
AOF does not turn Redis into a substitute for a durable relational or document database. Application records such as invoices, subscriptions, orders, and audit history should normally remain in the primary database.
RDB + AOF can be appropriate for higher-value state
Using both mechanisms can provide a broader recovery toolbox.
A team may use:
- RDB for compact periodic recovery artifacts;
- AOF for a smaller recovery-point gap;
- independent backups of persistence files;
- tested restart and restore procedures.
That combination is justified only when the workload's importance warrants the extra disk, monitoring, and recovery complexity.
For disposable cache data, enabling every durability mechanism usually creates unnecessary work.
No persistence can be the correct cache decision
For a pure cache, persistence may be unnecessary.
If every key can be rebuilt safely from a durable source of truth, restart behavior can simply be:
Redis restarts empty → application misses cache → durable database serves requests → cache warms again
The risks then shift from data loss to cache stampede, database load, and warm-up time.
A no-persistence design should therefore answer:
- can the durable source handle cache misses after restart?
- is cache warming gradual or bursty?
- are expensive keys rate-limited or pre-warmed?
- will users see unacceptable latency while the cache rebuilds?
Persistence is not mandatory merely because Redis supports it.
Workload role should choose the persistence model
| Workload | Typical starting point |
|---|---|
| Rebuildable read cache | No persistence or periodic RDB |
| Session store | RDB or AOF depending acceptable logout/data-loss window |
| Rate limits | Depends on whether resets are acceptable |
| Locks | Persistence usually not the main correctness mechanism |
| Queue / pending jobs | Stronger persistence and recovery testing |
| Durable business records | Use another durable primary database |
The key design rule is: temporary storage can still be production-critical. A session store may not be the source of truth, but losing all sessions can still cause a major customer incident.
Persistence needs disk and memory headroom
RDB snapshots and AOF rewrites create extra resource pressure.
Monitor:
- disk free space;
- persistence file size;
- snapshot duration;
- AOF rewrite duration;
- fork/copy-on-write memory pressure;
- write latency during persistence operations;
- restart time;
- backup transfer duration.
A Redis instance that runs comfortably at steady state can still fail during snapshot or rewrite work if capacity is too tight.
Keep operational headroom rather than sizing memory and disk to the average dataset alone.
Persistence is not a backup strategy by itself
RDB and AOF files on the same host can be lost with that host.
If the data matters, define:
- where persistence files live;
- whether copies leave the primary failure domain;
- backup frequency and retention;
- who can restore them;
- how restore integrity is validated;
- maximum acceptable data loss;
- maximum acceptable recovery time.
Persistence answers “what survives a restart?” Backup strategy answers “what survives infrastructure loss or logical destruction?”
Valkey uses the same core persistence concepts
Valkey documents RDB snapshots, AOF, no persistence, and combined RDB+AOF approaches. This makes persistence planning relevant to teams moving from Redis to Valkey.
Raff's managed Redis-compatible service is Managed Valkey. A managed service can operate snapshot/recovery infrastructure and host lifecycle for the team, while the application team still owns TTLs, eviction behavior, role separation, and the business meaning of recovered state.
Teams that need exact Redis configuration can self-host Redis on Raff VMs and control persistence settings directly.
Redis persistence checklist
- The workload role is documented.
- Acceptable data-loss window is defined.
- Restart behavior is tested.
- RDB schedule matches the recovery target if snapshots are used.
- AOF fsync policy matches durability needs if AOF is used.
- Disk has headroom for snapshots and rewrites.
- Persistence files are backed up off-host if the data matters.
- Queue/session roles are not treated like disposable cache by accident.
- Restore time is measured.
- The primary durable database remains the source of truth for business records.
Conclusion
RDB, AOF, both, or no persistence can all be correct Redis designs. The choice should follow the workload's acceptable data loss, recovery time, and ability to rebuild state.
Use RDB when periodic snapshots are enough, AOF when a smaller recovery gap matters, both when the workload justifies a stronger recovery toolbox, and no persistence when the dataset is truly disposable and safe to rebuild.