How Does Redis Persist Data? A Deep Dive into AOF, RDB, and Trade-offs

Redis persists data using three primary strategies—AOF (Append-Only File), RDB (Redis Database Snapshots), and a mixed approach—each balancing durability, recovery speed, and write latency differently.

Redis stores all data in memory for sub-millisecond latency, but it also provides on-disk persistence to survive process restarts or crashes. According to the ByteByteGoHq/system-design-101 repository, understanding these persistence mechanisms is critical for production deployments where data durability and availability requirements vary. This guide examines how Redis implements persistence according to the source analysis in data/guides/how-does-redis-persist-data.md, detailing the architectural trade-offs between consistency and performance.

Redis Persistence Strategies

Redis offers three distinct persistence modes, each optimized for different operational requirements regarding durability, recovery time, and latency impact.

AOF (Append-Only File): Maximum Durability

The Append-Only File logs every write command after it has been applied to the in-memory dataset. Unlike traditional write-ahead logging, Redis uses a write-after approach where commands are first executed in RAM, then recorded to the AOF log.

• Write latency: Non-blocking. The main thread does not wait for disk I/O, though the fsync policy (appendfsync) determines durability guarantees.
• Recovery: Replays the entire log sequentially, which can be slow for large datasets but provides the most recent state.
• Best for: Financial transactions or scenarios requiring maximum durability where longer restart times are acceptable.

RDB (Redis Database Snapshots): Fast Recovery

RDB snapshots capture point-in-time copies of the entire dataset. The main process forks a child process (bgsave) that writes the snapshot while the parent continues processing writes, utilizing copy-on-write memory sharing.

• Write latency: Minimal impact. Snapshots run in the background via forked processes.
• Recovery: Very fast. The binary snapshot loads directly into memory without replaying individual commands.
• Best for: Large caches where startup time is critical and occasional data loss of recent writes (between snapshots) is acceptable.

Mixed Mode: The Production Standard

Most production deployments enable both AOF and RDB simultaneously. On restart, Redis first loads the latest RDB snapshot for quick initialization, then replays the AOF log to bring the dataset up-to-date.

• Write latency: Combines background snapshots with asynchronous AOF writes.
• Recovery: Two-step process offering the fastest balance between speed and data freshness.
• Best for: General production systems requiring both quick restarts and minimal data loss.

Key Architectural Insights

The persistence implementation in Redis reflects several critical design decisions that balance speed with durability.

In-Memory Primary Store

All reads and writes operate exclusively in RAM. Persistence remains a secondary concern handled by background processes, preserving Redis's hallmark sub-millisecond latency.

Background Processing with Copy-on-Write

Both AOF rewriting (BGREWRITEAOF) and RDB snapshotting (BGSAVE) execute in forked child processes. This leverages the copy-on-write mechanism to avoid blocking the main thread while ensuring point-in-time consistency.

Write-After Logging Architecture

AOF logs commands after they modify the in-memory state, ensuring the critical path never stalls waiting for disk I/O. The log stores Redis commands rather than raw data pages, simplifying recovery logic but increasing replay time for large operation histories.

Configurable Durability Levels

The appendfsync setting controls fsync frequency:

• always: Fsync on every write (maximum durability, higher latency)
• everysec: Fsync once per second (common compromise)
• no: Let the OS handle syncing (fastest, least durable)

Configuration and Code Examples

Enable and manage persistence using these configuration snippets and CLI commands from the ByteByteGoHq/system-design-101 guides.

Enable AOF persistence in redis.conf:

appendonly yes
appendfsync everysec

Trigger RDB snapshots manually:

# Synchronous save (blocks main thread)

redis-cli SAVE

# Asynchronous snapshot (forks child process)

redis-cli BGSAVE

Compact AOF files to prevent unbounded growth:

redis-cli BGREWRITEAOF

Verify runtime persistence configuration:

redis-cli CONFIG GET appendonly
redis-cli CONFIG GET save

Example mixed persistence configuration:

# redis.conf

save 900 1      # Snapshot every 15 minutes if ≥1 key changed

save 300 10     # Snapshot every 5 minutes if ≥10 keys changed

appendonly yes
appendfsync everysec

Operational Trade-offs

Choosing between persistence strategies requires balancing competing system requirements.

Latency versus Durability

Enabling AOF with appendfsync always adds hundreds of microseconds per write, potentially impacting high-QPS workloads. The everysec policy offers a practical compromise for most use cases.

Recovery Time versus Data Loss

RDB snapshots load instantly but may lose data since the last snapshot interval (configurable via save directives). AOF preserves nearly all data but requires sequential log replay, extending restart times for high-volume instances.

Storage Overhead

AOF files grow continuously because they store every command. Periodic BGREWRITEAOF operations compact the log but temporarily double disk usage during the rewrite process. RDB files remain compact binary snapshots.

Operational Complexity

Managing both mechanisms requires tuning snapshot intervals, scheduling AOF rewrites, and monitoring forked processes for memory bloat. The mixed approach, while robust, increases the surface area for configuration errors.

Summary

• Redis offers three persistence modes: AOF for durability, RDB for speed, and mixed for production balance.
• AOF uses write-after logging where commands are stored after in-memory execution, ensuring non-blocking writes.
• RDB utilizes copy-on-write forking via BGSAVE to create point-in-time snapshots without stopping the main thread.
• The appendfsync configuration directly controls the latency-durability trade-off.
• Production deployments typically use mixed persistence, loading RDB snapshots first then replaying AOF logs for optimal recovery speed and data freshness.
• Background processes like BGREWRITEAOF prevent AOF files from growing indefinitely but require monitoring for temporary disk space usage.

Frequently Asked Questions

What is the difference between AOF and RDB in Redis?

AOF (Append-Only File) logs every write command sequentially, providing maximum durability but slower recovery times due to log replay. RDB (Redis Database Snapshots) creates compact binary point-in-time snapshots using forked processes, enabling fast restarts but potentially losing data since the last snapshot. According to the source analysis in data/guides/how-does-redis-persist-data.md, AOF is preferred for durability-critical applications while RDB suits large caches where fast startup matters more than recent data loss.

How does Redis handle persistence without blocking the main thread?

Redis leverages copy-on-write forking to execute persistence tasks in background child processes. When running BGSAVE for RDB snapshots or BGREWRITEAOF for log compaction, the main process forks a child that shares memory pages with the parent. The child writes the snapshot or rewrites the AOF file while the parent continues processing client requests, ensuring sub-millisecond latency remains unaffected during persistence operations.

Which Redis persistence mode should I use for production?

Most production systems should use mixed persistence, enabling both AOF and RDB simultaneously as detailed in the ByteByteGoHq/system-design-101 guides. This configuration loads the RDB snapshot first for rapid initialization, then replays the AOF log to recover the most recent writes. The combination balances fast restart times with minimal data loss, though it requires monitoring disk usage and tuning save intervals alongside appendfsync policies.

How often should I run BGREWRITEAOF?

Run BGREWRITEAOF when AOF files grow significantly larger than their corresponding RDB snapshots or when disk space concerns arise. Redis can trigger this automatically based on the auto-aof-rewrite-percentage and auto-aof-rewrite-min-size configuration parameters. Manual execution via redis-cli BGREWRITEAOF is useful before maintenance windows or when you observe AOF files consuming excessive storage, though note the process temporarily doubles disk usage during the rewrite.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}