Redis RDB vs AOF: Persistence Trade-offs at Scale

"Redis RDB vs AOF" is one of the most searched Redis questions for a reason: the default answer that worked for a 2GB cache falls apart once you're pushing tens of thousands of writes per second through a multi-tenant SaaS. The short answer is that RDB is cheap until it forks, AOF is safe until it fsyncs, and most production systems at scale should run a hybrid of both rather than picking one. This post walks through why, with the numbers that actually matter when you're sizing persistence for sustained load.

RDB and AOF are solving two different problems

RDB (Redis Database) is a point-in-time snapshot. On a schedule, Redis forks a child process, and that child walks the in-memory dataset and writes a compact binary file to disk while the parent keeps serving traffic. AOF (Append Only File) is a write log: every command that mutates data gets appended to a file, and Redis replays that log on restart to rebuild state. RDB answers "what did the data look like a few minutes ago?" AOF answers "what is the complete, ordered history of writes?" Those are different guarantees, and they fail differently under load.

The real cost: fork pauses and fsync overhead under sustained writes

On a quiet dataset, RDB's fork is nearly free. Under sustained high write throughput it isn't. Linux uses copy-on-write for the forked child, so every write your primary process makes after the fork duplicates the touched memory pages. On a large, write-heavy keyspace (say 20GB+ with a high mutation rate), that copy-on-write churn can double memory usage temporarily and introduce latency spikes of tens to hundreds of milliseconds while the fork completes — precisely when you can least afford them.

AOF's cost shows up differently, through the appendfsync setting. With appendfsync always, Redis calls fsync after every write, which is the safest option and also the slowest — throughput can drop 50-80% depending on disk speed, which is why AOF-heavy deployments should run on NVMe or provisioned-IOPS storage, not burstable network volumes. appendfsync everysec batches the fsync to once per second and is the practical default for most teams: you risk losing up to one second of writes on a hard crash, but throughput overhead stays low. appendfsync no defers to the OS entirely, which is fast but reintroduces unpredictable data-loss windows tied to kernel flush behavior, not your application.

How much data can you actually afford to lose

This is a recovery-point-objective conversation, not just a Redis config choice. If Redis is purely a cache in front of PostgreSQL or MySQL, losing the last few minutes of writes on crash is a non-event — the cache just warms up again from the source of truth, and you may not need persistence at all. If Redis is your session store, a queue backend (BullMQ, Laravel Horizon jobs waiting to run), or a rate-limiter with business consequences, a few minutes of silently vanished writes means logged-out users, dropped jobs, or a rate limit that resets and lets an abuser through. Map each Redis-backed feature to "can this data be regenerated cheaply?" before you pick a persistence strategy — the answer is rarely the same across every use case sharing one Redis instance.

Recovery time matters more than people think

Teams size persistence around data-loss risk and forget about recovery time, which is just as operationally important under load. RDB files load fast because they're already in Redis's native binary format. A large pure-AOF log, especially one that hasn't had a rewrite in a while, can take minutes to replay on startup — and during that replay, that node is not serving traffic. In a failover scenario where a replica is being promoted under production load, minutes of unavailability is the difference between a blip and an incident. This is the strongest argument for AOF rewrite scheduling (auto-aof-rewrite-percentage) and for testing actual restart times against your real dataset size, not a synthetic benchmark.

The hybrid answer most production systems should use

Redis has supported RDB-preamble AOF since version 4, and it's the sensible default for most serious production workloads today: set aof-use-rdb-preamble yes, and Redis writes AOF rewrites as a compact RDB snapshot followed by the incremental commands since that snapshot. You get RDB's fast load time and AOF's tight data-loss window in one file. Pair that with appendfsync everysec, save intervals tuned to your write volume for the RDB side, and replicas that can serve reads (and take over) if the primary's fork or fsync ever causes a latency spike you can't tolerate on that node alone.

• aof-use-rdb-preamble yes — hybrid AOF for fast recovery with tight durability
• appendfsync everysec — the throughput/durability balance for almost all workloads
• auto-aof-rewrite-percentage 100 — keep the AOF file from growing unbounded and slowing restarts
• Run persistence-heavy primaries on local NVMe or provisioned IOPS, never network storage with unpredictable latency
• Test actual restart time on a production-sized dataset before you need it during an incident

A decision framework by workload

1. Cache only, fully regenerable from Postgres/MySQL: RDB with a longer save interval, or disable persistence entirely and rely on replication for availability.
2. Session store: AOF with everysec, hybrid preamble on — a lost session costs a re-login, not lost work, but you still don't want minutes of exposure.
3. Queue or job broker (BullMQ, Horizon): AOF with everysec at minimum; consider appendfsync always for payment or compliance-adjacent jobs where a dropped job has real cost.
4. Primary data store or leaderboard/analytics state with no upstream source of truth: hybrid AOF plus cross-AZ replication — persistence alone is not a backup strategy.

Getting this wrong is expensive in ways that don't show up in a load test

A load test tells you Redis can handle your write volume. It doesn't tell you what happens when that fork's copy-on-write spike lands during your traffic peak, or how long your replica takes to come back online after a forced restart with a three-year-old AOF file that's never been rewritten. Persistence decisions are cheap to get right up front — a few lines in redis.conf and a restart-time test — and expensive to discover wrong during an incident, when the dataset is bigger, the traffic is higher, and everyone is watching the dashboard.