Understanding Redis Persistence: RDB vs AOF and Performance Tips

Introduction

Redis is a widely used in‑memory database, but many users only know how to use it without understanding its internal persistence mechanisms. This article introduces the two main persistence solutions—RDB and AOF—through five aspects.

RDB Persistence

RDB creates a snapshot of the current dataset and saves it to disk. The snapshot file is stored in the directory configured by dir with the name defined by dbfilename. By default Redis compresses the RDB file using the LZF algorithm.

Manual Trigger

Commands: save (blocking, deprecated) and bgsave (forks a child process, only the fork phase blocks briefly).

Automatic Trigger

Triggered by save m n configuration.

Master automatically runs bgsave when a replica performs a full sync.

Executing debug reload also triggers a save.

During shutdown without AOF enabled, Redis runs bgsave.

RDB Execution Flow

After bgsave, Redis checks for existing AOF or RDB child processes; if present, it returns.

The parent process forks a child; the parent is blocked during fork.

The child generates a temporary snapshot from the parent’s memory, then replaces the original RDB file. The lastsave command shows the timestamp of the latest RDB.

The child signals the parent, which updates statistics.

RDB Advantages

Compact binary snapshot suitable for backups and full replication; e.g., schedule bgsave every six hours and copy the file to a remote system.

Loading an RDB file is much faster than replaying an AOF file.

RDB Disadvantages

Cannot provide real‑time or second‑level durability because each bgsave requires a heavyweight fork.

Binary format changes across Redis versions, potentially causing incompatibility with older servers.

AOF Persistence

AOF (Append‑Only File) records every write command as a log, enabling near‑real‑time durability and becoming the mainstream persistence method in modern Redis deployments.

Enabling AOF

Set appendonly yes in the configuration (disabled by default).

File name is defined by appendfilename (default appendonly.aof).

Path is the same dir used for RDB.

AOF Execution Flow

The process consists of four steps: command write, file sync, file rewrite, and restart load (illustrated in the diagram).

Command Write

Commands are appended to the AOF buffer in Redis’ text protocol format, e.g.:

*3
$3
set
$5
hello
$5
world

Writing to the buffer ( aof_buf) decouples command execution from disk I/O, allowing Redis to balance performance and safety using different sync strategies.

File Sync

always

: sync on every write (severely limits throughput, not recommended). no: never sync (high performance but risk of data loss). everysec (default): sync once per second, offering a good trade‑off.

File Rewrite

Purpose: compress the AOF file by rewriting the in‑memory dataset as a minimal set of commands.

Triggered manually with bgrewriteaof or automatically based on auto-aof-rewrite-min-size and auto-aof-rewrite-percentage.

During rewrite, the main thread continues serving commands, writing new data to the old AOF while the child creates a new compact file.

Rewrite removes obsolete commands (e.g., del key) and merges multiple writes (e.g., multiple lpush into a single command).

Both RDB and AOF replace the old file by renaming a temporary file after the rewrite completes.

AOF Advantages

Provides durability with configurable fsync strategies; the default everysec loses at most one second of data while maintaining good performance.

AOF Disadvantages

File size is typically larger than RDB, and write speed can be slower depending on the sync policy.

Recovery speed is slower compared to RDB.

RDB vs AOF

RDB creates binary snapshots at intervals, using a forked child to write a compressed file.

AOF logs every write operation as plain text, allowing near‑real‑time recovery but producing larger files.

Restart Loading

On server restart, Redis checks for an AOF file first; if present, it replays the log. If AOF is absent, it falls back to loading the latest RDB snapshot. The flow is illustrated in the diagram.

Performance Issues and Solutions

Both RDB snapshot and AOF rewrite involve fork, which can block the main process.

Prefer physical machines or virtualization that handles fork efficiently.

Limit each Redis instance’s memory to ≤10 GB to keep fork time reasonable.

Configure Linux memory allocation to avoid out‑of‑memory during fork.

Reduce fork frequency by relaxing AOF rewrite triggers and avoiding unnecessary full syncs.

Conclusion

The article provides a comprehensive overview of Redis persistence mechanisms, essential for both operations and backend developers. Understanding RDB and AOF helps choose the right strategy and mitigate performance impacts.