Hybrid Persistence (RDB + AOF)

intermediate redis persistence rdb aof

Hybrid persistence is what most production Redis deployments actually run. You enable both RDB and AOF — but with a twist. The AOF rewrite uses RDB format for the base, then appends new commands on top.

In simple language — think of it like a photo album with sticky notes. The RDB snapshot is the photo (everything compactly captured at one moment). The AOF tail is the sticky notes describing what happened since the photo was taken. Together you get a full picture, fast.

Why hybrid?

Pure RDB → fast restart but you lose data between snapshots. Pure AOF → great durability but slow restart on big datasets (replay every command).

Hybrid → restart loads the RDB chunk fast, then replays only the small AOF tail. Best of both.

RDB vs AOF vs Hybrid
RDB only
Restart: fast
Durability: minutes lost
File: small
AOF only
Restart: slow (replay)
Durability: ≤ 1s lost
File: large
Hybrid
Restart: fast
Durability: ≤ 1s lost
File: medium

How it works

When AOF rewrite runs (BGREWRITEAOF), instead of writing out a giant list of commands, Redis dumps the dataset in RDB binary format as the prefix of the new AOF file. Then any commands that came in during the rewrite get appended as regular RESP commands.

So the file looks like:

[ RDB binary header ]
compact snapshot of all keys at rewrite time
[ RESP commands ]
writes that happened after rewrite

On restart Redis detects the RDB prefix, loads it in one shot, then replays the tail. Quick startup, almost no data loss.

Config

# redis.conf — recommended production setup
appendonly yes
appendfsync everysec
aof-use-rdb-preamble yes      # enables hybrid (default since Redis 5)

# keep RDB too — useful for backups
save 3600 1
save 300 100
save 60 10000

aof-use-rdb-preamble yes is what makes the hybrid magic happen. It’s been the default since Redis 5, so unless you’re on something ancient, you’re already getting this.

When to skip hybrid

  • Pure cache, no value in persistence — disable both. Redis is fast, save the disk I/O.
  • Replica-only durability — you might run AOF off, RDB only, and rely on async replication to a persistent secondary.
  • Memory tight, big dataset — the fork() during snapshots/rewrites can be expensive. Schedule it during low traffic, or use no-appendfsync-on-rewrite yes to dodge fsync during rewrites.

What to choose — decision tree

Is Redis the source of truth for any data?
├── No (just cache)
│   └── Disable persistence. Save disk I/O.
└── Yes
    ├── Can you tolerate 1s of data loss?
    │   ├── Yes → Hybrid (RDB + AOF everysec) ← default for most apps
    │   └── No  → AOF with fsync always (slowest but bulletproof)
    └── Need fast restarts AND backups?
        └── Hybrid. Always hybrid.

For 90% of real-world Redis deployments, hybrid with everysec fsync is the right answer. It’s the default in modern Redis for good reason.