Reference · Cheat sheet

Persistence: RDB vs AOF

Snapshot vs log — and the fork trick. Print it, pin it.

From lesson 0005See also glossary

Side by side

	RDB (snapshot)	AOF (log)
What	Binary point-in-time dump	Append log of every write, replayed on start
Trigger	`save N M`, `BGSAVE`	continuous; `BGREWRITEAOF` to compact
Durability	Lose minutes since last snapshot	Lose ≤ ~1s (`everysec`)
File	Compact — ideal backup/DR	Bigger; needs rewrite
Restart	Faster on big datasets	Slower (replay)

appendfsync (AOF durability dial)

Policy	fsync	Worst-case loss
`always`	every write	≈ none (slowest)
`everysec` (default)	1×/second	~1s (bounded ~2s)
`no`	OS decides	~30s

fork() + copy-on-write

Persisting forks a child that does the disk I/O; parent keeps serving.
Parent + child share pages; only pages the parent writes get copied.
Extra memory ∝ data changed during the save, not the whole dataset.
BGSAVE and BGREWRITEAOF both use this trick; SAVE blocks.

Latency gotcha

fork() on a big instance can stall the single command thread for milliseconds–seconds (head-of-line blocking). Bigger dataset + more write churn = bigger spike.

Which to use

Both for PostgreSQL-comparable safety: RDB = cheap backups + fast restart, AOF = tight (~1s) loss window. RDB-only if a few minutes of loss is acceptable. AOF-only is discouraged (keep occasional RDB for backups/restarts).

← lesson 0005 · Sources: Redis Docs — Persistence · antirez — persistence demystified