Mastering Redis Persistence: When to Use RDB vs AOF

High Availability Overview

Redis achieves high availability through four key mechanisms: data persistence, master‑slave replication, automatic failover, and clustering.

Persistence Mechanisms

Redis provides two primary persistence methods: RDB (snapshot) and AOF (append‑only log).

RDB

RDB (Redis Database Backup) creates a point‑in‑time snapshot of the entire dataset. The SAVE or BGSAVE command generates an RDB file that contains a near‑complete copy of the instance’s data.

Advantages

RDB files are compressed, so the file size is smaller than the in‑memory dataset.

Loading an RDB file on restart is fast, enabling rapid recovery.

Disadvantages

The snapshot represents data at a single moment; recent writes may be lost.

Generating an RDB file consumes considerable CPU and memory resources.

Typical Use Cases

Full data synchronization for master‑slave replication.

Periodic database backups.

Scenarios where occasional data loss is acceptable, such as fast recovery after a crash.

RDB generation can be scheduled via configuration. BGSAVE runs in the background using the operating system’s Copy‑On‑Write (COW) mechanism (fork). The fork creates a child process that initially shares the parent’s memory pages; the parent continues to serve client requests while the child writes the snapshot to disk. After the fork, the parent allocates new memory for subsequent writes, separating the two processes’ memory spaces.

AOF

AOF (Append Only File) records every write command in a log file, providing a more up‑to‑date representation of the dataset. AOF can be enabled in the Redis configuration file.

Three appendfsync policies control when the AOF buffer is flushed to disk: appendfsync always – flush on every write (maximum durability, highest I/O cost). appendfsync everysec – flush once per second (balanced durability and performance). appendfsync no – rely on the operating system’s flushing (best performance, lowest durability).

AOF offers higher data safety than RDB because it logs each command, but the file grows over time. Redis can automatically trigger an AOF rewrite to compact the file, which also consumes CPU resources.

AOF is especially suitable for workloads that cannot tolerate data loss, such as financial transaction systems.

Performance Considerations

Choosing an appendfsync policy involves a trade‑off between write throughput and data safety. In practice, appendfsync everysec provides a good balance, preserving most writes while maintaining acceptable performance.

Conclusion

RDB is ideal for fast restarts, backups, and full data syncs, whereas AOF delivers higher durability for write‑intensive, loss‑sensitive applications. Combining both mechanisms can give you the safety of AOF with the quick recovery of RDB.