Redis Persistence: RDB vs AOF, Explained

Redis persistence is what lets an in-memory Redis instance survive a restart or crash without losing its dataset. Redis keeps everything in RAM for speed, so without persistence a process restart means an empty database. There are two independent, combinable mechanisms for writing that data to disk: RDB snapshots, which dump the whole dataset at a point in time, and the AOF (append-only file), which logs every write as it happens. They make very different trade-offs between durability, disk I/O, and restart speed.

RDB: point-in-time snapshots

RDB (Redis Database) persistence writes a compact, compressed binary snapshot of the entire dataset to disk. Snapshots happen on a schedule you configure — for example, “save if at least one key changed in the last 15 minutes, or 10 changed in 5 minutes” — or on demand.

The save itself uses a background fork: Redis forks a child process, and that child writes the snapshot while the parent keeps serving reads and writes uninterrupted. Because the operating system’s copy-on-write behavior only duplicates memory pages as they’re modified, the fork is usually cheap — but on a write-heavy workload with a large dataset, memory usage can spike noticeably during the save, since every page a client writes to during the fork gets duplicated.

RDB’s strengths are restart speed and compactness: loading a single binary file back into memory is fast, and the file is small enough to ship off to backup storage. Its weakness is the durability window — any write since the last snapshot is gone if the process crashes.

AOF: logging every write

The append-only file takes the opposite approach. Instead of periodic snapshots, Redis appends every write command to a log as it’s processed. On restart, Redis replays the log from the start to reconstruct the dataset.

Durability here is governed by the fsync policy, which controls how often the log is actually flushed to disk rather than sitting in an OS buffer:

• always — fsync on every write. Safest, slowest.
• everysec — fsync once per second (the common default). Bounds data loss to roughly one second of writes.
• no — let the operating system decide when to flush. Fastest, least durable.

This is the same trade-off a write-ahead log makes in a traditional relational database: fsync more often for durability, less often for throughput. Because AOF logs commands rather than final state, the file grows continuously and would eventually record far more data than the dataset actually contains — including commands that later got overwritten or deleted. Redis handles this with a background rewrite that compacts the log down to the minimum set of commands needed to reconstruct the current dataset, using the same fork-based approach as an RDB save.

Hybrid persistence

Since Redis introduced hybrid AOF, a rewritten AOF file starts with an RDB-format preamble — a full snapshot — followed by AOF-style commands for everything written after that point. This combines RDB’s fast loading (read the snapshot first) with AOF’s fine-grained durability (replay only the recent tail), without needing to choose one mechanism exclusively.

RDB vs AOF at a glance

	RDB	AOF
What it stores	A snapshot at a point in time	A log of every write command
Durability window	Since the last snapshot (can be minutes)	Since the last fsync (as low as ~1 second)
Restart speed	Fast — load one binary file	Slower for large logs, unless using the hybrid preamble
File size	Small, compressed	Larger, unless periodically rewritten
Write-path overhead	Low — only during background saves	Higher, tunable via fsync policy
Best for	Backups, disaster recovery, tolerant of some data loss	Minimizing data loss on crash

Choosing a configuration

If Redis is only a cache in front of a real datastore — see our Redis vs Memcached comparison for when that’s the right call — persistence may not matter at all. A restart just means a cold cache; the application refills it from the source of truth. Running with persistence disabled entirely is a legitimate choice in that case, and it avoids the fork and disk-I/O overhead altogether.

If Redis is holding data nothing else has a copy of — session state, counters, queues — persistence stops being optional. Most production setups combine both mechanisms: RDB snapshots for periodic backups and fast cold starts, AOF with everysec for a tight bound on how much can be lost in a crash. That combination costs more disk I/O and some write latency, but for a primary datastore the trade is usually worth it.

It’s worth being clear about what persistence doesn’t do. Writing to disk protects against a process restart or host reboot, but a single disk failure still loses everything written to it — persistence is not a substitute for replication, which protects against losing the whole node. Persistence is also unrelated to key eviction: LRU vs LFU eviction policies decide which keys to drop when Redis is out of memory while running; RDB and AOF decide what happens when the process stops running. They solve different problems and are usually configured together, not instead of each other.

The takeaway

RDB gives fast, compact snapshots at the cost of a durability gap between saves. AOF logs every write for much tighter durability at the cost of larger files and, depending on the fsync policy, more disk I/O per write. Hybrid persistence gets the fast load of RDB with the low data-loss window of AOF by combining both in one file. Choose based on how much data you can afford to lose in a crash — a pure cache can often run with no persistence at all, while a primary datastore usually wants both mechanisms running together.