Redis Persistence Decision: Choosing Between RDB, AOF, and Hybrid Modes

Decision and constraints

You must pick a persistence mechanism for a primary Redis instance that matches your tolerance for data loss, write‑latency budget, disk I/O capacity, and restart time.

• Acceptable data loss window (seconds)
• Write throughput and p99 latency target
• Available disk I/O and storage growth rate
• Maximum allowed time to reload data after a crash or planned restart

These constraints vary by workload: a cache can survive minutes of loss, a session store may need sub‑second durability, and a financial ledger often requires near‑zero loss.

Supported options compared

Trade‑offs in practice

RDB is created by BGSAVE, which forks the Redis process. Between saves the instance runs with almost no persistence overhead, but each fork copies memory and can cause latency spikes on large datasets. Recovery is quick because only one file is read. The downside is that any writes after the last snapshot are lost on a crash.

AOF logs every write command. With appendfsync everysec you gain durability within about one second while keeping write latency moderate. appendfsync always gives the strongest guarantee but adds a fsync per command, increasing latency. appendfsync no maximizes throughput but risks losing many seconds of data. AOF files grow continuously and require periodic background rewrites (BGREWRITEAOF), which fork the process and can temporarily spike CPU and disk I/O.

Hybrid mode writes a base RDB snapshot at the start of the AOF file followed by AOF‑format commands. This keeps the durability guarantees of the chosen fsync policy while reducing replay time because the loader can first restore the RDB base and then replay only the incremental AOF tail. Hybrid files are larger than pure RDB but smaller than a growing pure AOF of the same age.

Changing persistence mode at runtime is not instantaneous. Switching from RDB to AOF (or adjusting the fsync policy) triggers a full rewrite or requires a restart. To avoid downtime, you can promote a replica that already runs the desired configuration or perform a rolling restart with a replica‑swap strategy.

Concrete validation for AOF everysec

The following steps show how to enable AOF with an every‑second fsync and verify that a write survives a simulated power loss. Perform these actions only on a non‑production test instance.

1. Configure Redis

appendonly yes
appendfsync everysec
# Optional tuning for large datasets
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

Start or reload Redis with this file. Confirm the settings:

redis-cli -p <redis-port> CONFIG GET appendonly
redis-cli -p <redis-port> CONFIG GET appendfsync

Expected output: appendonly → yes, appendfsync → everysec.

2. Write a test key

redis-cli -p <redis-port> SET persist:check <test-value>
redis-cli -p <redis-port> GET persist:check

The GET should return the value you just set.

3. Simulate a crash

Risk: this command terminates the Redis process abruptly. Do not run it against a production server.

redis-cli -p <redis-port> DEBUG SEGFAULT

4. Restart Redis

Start Redis again using the same data directory and configuration file.

5. Verify persistence

redis-cli -p <redis-port> GET persist:check

If the key is present, the write was flushed to disk within the one‑second fsync window. If the key is missing, the write was still in the OS page cache at the moment of the simulated power loss.

6. Validate AOF integrity

redis-check-aof --check <data-dir>/appendonly.aof

A clean exit code indicates the AOF file is structurally sound. You can also monitor the rewrite process with:

redis-cli -p <redis-port> INFO persistence

Look for the fields aof_rewrite_in_progress and latest_aof_rewrite_duration_sec to spot any latency spikes during background rewrites.

Limitations and operational checks

AOF everysec does not guarantee zero loss; a crash within the one‑second window can lose recent writes. Disk failures can corrupt the AOF, so keep periodic backups or use a replica for redundancy.

Monitor latency during BGSAVE (if you ever enable RDB snapshots) and BGREWRITEAOF. Large forks increase memory pressure; consider tuning vm.overcommit_memory and enabling active-defrag to reduce fragmentation.

When moving to a different persistence mode in production, test the change on a replica, promote it, or use a rolling restart with a replica‑swap to avoid a window of write unavailability.