Redis RDB vs AOF: Persistence & Data Loss Trade-Offs

RDB and AOF solve different Redis persistence goals. RDB creates periodic point-in-time snapshots; AOF records write operations so Redis can replay them after restart. RDB is compact and usually faster to restore, but it can lose changes made after the last snapshot. AOF can reduce the data-loss window substantially—Redis documents appendfsync everysec as the suggested/default compromise, with roughly one second of potential data loss in a severe failure—but it adds write I/O and larger persistence files.

For higher-value state, Redis can use RDB and AOF together. Since Redis 7, AOF uses a multi-part format with a base file plus incremental AOF files. When both RDB and AOF are enabled, Redis uses the AOF dataset during restart because it is considered the more complete copy.

Raff Technologies offers a managed Redis-compatible path through Managed Valkey, while teams that need exact Redis persistence controls can self-host Redis on a Raff VM. In either model, persistence should follow the workload's recovery requirements rather than being enabled by habit.

Redis RDB vs AOF: quick comparison

The practical choice is not “which is faster?” but how much acknowledged data can the application lose, how quickly must it recover, and can the state be rebuilt from another durable source?

What is Redis RDB persistence?

RDB persistence creates a snapshot of the in-memory dataset at a point in time. Redis writes the dataset to an RDB file according to configured save rules or explicit snapshot commands.

A simple timeline looks like this:

12:00 RDB snapshot completes
12:01 writes
12:02 writes
12:03 host/process failure

If the 12:00 snapshot is the latest valid RDB file, changes made after it may not be present after recovery.

That makes RDB a good fit when:

• the application can tolerate a recovery gap;
• the dataset is mostly rebuildable cache or derived state;
• compact backup artifacts are useful;
• lower continuous write overhead matters;
• fast loading from a snapshot is valuable;
• the business recovery point objective can be met by the snapshot schedule.

RDB is less suitable when losing the most recent minutes of queue, session, or coordination state would create unacceptable customer impact.

RDB schedule effectively sets the recovery point

An RDB configuration is also an RPO decision.

If snapshots are created every five minutes, a catastrophic failure immediately before the next snapshot can expose close to five minutes of unpersisted changes. The exact risk depends on the save rules and whether the latest snapshot completed successfully.

Do not choose an RDB schedule only from CPU or disk convenience. Match it to the application's acceptable data-loss window.

What is Redis AOF persistence?

AOF—Append Only File—records write operations so Redis can reconstruct the dataset by replaying them after restart.

This can provide a smaller recovery gap than periodic RDB snapshots, but the durability depends heavily on the appendfsync policy.

Redis currently documents three main policies:

For most production applications considering AOF, everysec is the useful starting point because it balances durability and performance better than syncing every write.

AOF is attractive when:

• recent write loss must be minimized;
• queue or session state has a tighter recovery target;
• the storage layer can handle continuous persistence I/O;
• the team can monitor AOF size and rewrite activity;
• a one-snapshot-per-several-minutes RPO is not acceptable.

AOF still does not turn Redis into the ideal source of truth for invoices, orders, subscriptions, audit history, or other durable business records. Those usually belong in a database designed as the authoritative system of record.

Redis 7+ uses multi-part AOF

Modern Redis AOF is not simply one ever-growing log file.

Since Redis 7, AOF uses a multi-part format. Redis can maintain:

• a base AOF file representing the dataset at rewrite time;
• one or more incremental AOF files containing later changes;
• a manifest that tracks the active AOF parts.

This improves AOF rewrite management and changes what operators should expect to see on disk.

For self-hosted Redis, backup, restore, file-copy, and monitoring procedures should therefore be based on the current AOF layout rather than assuming a single legacy appendonly.aof file is the complete persistence state.

RDB vs AOF: which should you use?

Use RDB when the workload can tolerate the snapshot recovery gap and values compact backups, lower continuous write overhead, and straightforward point-in-time recovery.

Use AOF when the workload requires a smaller data-loss window and the added write I/O and file-management overhead are acceptable.

Use RDB + AOF when the state is important enough that both a compact snapshot path and a more granular write log are valuable.

Use no persistence when the dataset is truly disposable and safely rebuildable from another source.

A useful starting table is:

Temporary data can still be production-critical. A session store is not the system of record, but losing every active session may still be a serious incident.

What happens when RDB and AOF are both enabled?

Redis supports running RDB and AOF together.

When both are enabled, Redis uses AOF to reconstruct the dataset during restart because the AOF is expected to contain the more complete version of the data.

RDB still provides value in this configuration:

• compact periodic recovery artifacts;
• convenient off-host backups;
• faster disaster-recovery options in some workflows;
• an additional recovery path if an AOF-related problem occurs;
• easier point-in-time archival.

Using both is not automatically better for every workload. It increases disk activity, storage use, monitoring, and recovery complexity. A disposable cache may not need either mechanism; a production queue may justify both plus independent backups.

RDB and AOF have different performance costs

Persistence affects more than disk space.

RDB resource impact

RDB snapshots can create temporary pressure from:

• process forking;
• copy-on-write memory;
• snapshot I/O;
• temporary disk-space requirements;
• snapshot duration on large datasets.

A server that is comfortably sized for steady-state memory can still experience pressure during snapshot work.

AOF resource impact

AOF adds:

• continuous append I/O;
• fsync activity according to policy;
• growing persistence files between rewrites;
• AOF rewrite work;
• additional disk-space needs during rewrite/compaction;
• longer recovery replay for larger write histories.

Capacity planning should leave headroom for persistence operations, not only for the in-memory dataset itself.

Monitor at least:

• used memory and RSS;
• disk free space;
• persistence file size;
• last successful RDB save;
• RDB save duration;
• AOF rewrite status and duration;
• persistence errors;
• write latency during persistence operations;
• restart/restore time.

Persistence does not replace backups

RDB and AOF answer:

What can Redis reconstruct after a process or host restart when the persistence files are still available?

A backup strategy answers:

What can we recover after the host, disk, account, or persistence files themselves are lost or corrupted?

Keeping RDB or AOF only on the same host is therefore not sufficient for important state.

If the data matters, define:

• an off-host or independent copy;
• backup frequency;
• retention;
• encryption/access controls;
• restore ownership;
• restore validation;
• maximum acceptable data loss (RPO);
• maximum acceptable recovery time (RTO).

A persistence file that has never been restored successfully is only an untested recovery assumption.

For the wider recovery model, see RPO vs RTO for Cloud Backups and Database Restore Testing.

No persistence can be correct for a pure cache

If every key is safely rebuildable, running Redis without persistence can be a valid production design.

Recovery becomes:

Redis restarts empty
→ application misses cache
→ durable source serves requests
→ cache warms again

The operational risk is then cold-cache pressure, not loss of authoritative data.

Before using no persistence, verify:

• the primary database can survive the temporary miss rate;
• expensive keys can be rebuilt safely;
• cache warming will not create a thundering-herd problem;
• request latency during warm-up is acceptable;
• the application behaves correctly when the cache is unavailable.

Do not enable AOF merely because “production Redis should be persistent” if the workload is designed to be disposable.

Valkey uses the same RDB and AOF concepts

Valkey supports RDB and AOF persistence concepts, including using them together. This makes the same recovery questions relevant to teams moving between Redis and Valkey.

Migration still needs version awareness. Valkey documents compatibility with Redis OSS 2.x through 7.2.x RDB/AOF files for Valkey 7.2+ migration paths, while later Redis Community Edition persistence files should not be assumed compatible automatically.

If persistence files will be copied during migration, record:

source Redis version
→ source persistence mode
→ target Valkey version
→ supported file-compatibility path
→ restore validation

For the broader compatibility decision, see Redis vs Valkey: Compatibility, Operations, and Migration.

How this maps to Raff

Raff's managed Redis-compatible service is Managed Valkey. A managed service reduces host-level persistence, patching, and service-lifecycle work, while the application team still owns the business meaning of cache, sessions, queues, TTLs, and acceptable data loss.

Teams that need exact Redis configuration, direct persistence-file access, custom modules, or host-level control can self-host Redis on a Raff VM.

Do not choose managed or self-hosted Redis-compatible infrastructure only from persistence features. Choose from the responsibility boundary:

Want less platform operations
→ evaluate Managed Valkey

Need exact Redis persistence/host controls
→ self-host Redis on a VM

Use the live Managed Databases and Raff VM pages for current service scope rather than static plan details in this guide.

Redis persistence production checklist

• Workload role is documented: cache, sessions, queue, stream, lock, or other state.
• Acceptable data-loss window is defined.
• RDB snapshot schedule matches the intended RPO if RDB is used.
• appendfsync policy is explicitly chosen if AOF is used.
• AOF multi-part files are included in self-hosted backup/recovery procedures.
• Disk has headroom for snapshots and AOF rewrites.
• Memory has headroom for fork/copy-on-write behavior.
• Persistence failures are monitored.
• Off-host backups exist if the state matters.
• Restore time has been measured.
• Cache warm-up behavior is understood if persistence is disabled.
• Durable business records remain in the appropriate primary database.

Conclusion

For Redis RDB vs AOF, RDB is the simpler point-in-time snapshot model and AOF is the finer-grained write-log model.

Choose RDB when a snapshot-defined recovery gap is acceptable. Choose AOF when the workload needs a smaller data-loss window and can absorb the extra I/O and file-management work. Use both when the workload justifies multiple recovery paths, and keep independent backups whenever the persisted state actually matters.

The persistence mode should follow RPO, RTO, workload role, and recovery testing—not a generic rule that every production Redis instance needs the same configuration.

Sources

• Redis Persistence
• Valkey Migration from Redis
• Raff Managed Valkey
• Raff Managed Databases
• Product and technical details reviewed: 2026-09-14