RDB vs AOF comparison in Redis - Performance Comparison
When saving data in Redis, two main methods are used: RDB and AOF. Each method takes time to save data, and this time changes as the data grows.
We want to understand how the time to save data grows with the amount of data for both methods.
Analyze the time complexity of saving data using RDB snapshot and AOF append-only file.
# RDB snapshot
SAVE
# AOF append
APPENDONLY yes
# Commands are appended as they happen
SET key value
INCR counter
DEL key
RDB saves the whole dataset at once. AOF saves each command as it happens.
Look at what repeats when saving data.
- Primary operation for RDB: Writing the entire dataset to disk in one go.
- How many times: Once per snapshot, but the work depends on dataset size.
- Primary operation for AOF: Appending each command to the file as it happens.
- How many times: Once per command, so many times as commands run.
How does saving time grow as data grows?
| Input Size (n) | RDB Approx. Operations | AOF Approx. Operations |
|---|---|---|
| 10 keys | Write 10 keys at once | Append 10 commands one by one |
| 100 keys | Write 100 keys at once | Append 100 commands one by one |
| 1000 keys | Write 1000 keys at once | Append 1000 commands one by one |
RDB time grows with total data size because it writes all at once. AOF time grows with number of commands because it writes each command separately.
Time Complexity: O(n) for both, but with different meanings.
RDB time grows linearly with dataset size when saving snapshots. AOF time grows linearly with number of commands appended.
[X] Wrong: "RDB is always faster because it saves less often."
[OK] Correct: RDB writes the whole dataset at once, which can take longer if data is large. AOF writes smaller pieces more often, so total time depends on command volume.
Understanding how Redis saves data helps you explain trade-offs in real systems. It shows you can think about how work grows with data, a key skill in many jobs.
"What if AOF was rewritten less often, batching commands? How would that affect time complexity?"
Practice
Solution
Step 1: Understand RDB persistence
RDB saves the dataset by creating snapshots at set intervals.Step 2: Compare with AOF
AOF logs every write operation, not snapshots.Final Answer:
RDB (Redis Database snapshot) -> Option BQuick Check:
Snapshot saving = RDB [OK]
- Confusing AOF with snapshot saving
- Thinking both save snapshots
- Believing neither saves snapshots
Solution
Step 1: Identify AOF enabling command
The command to enable AOF isCONFIG SET appendonly yes.Step 2: Check other options
CONFIG SET save "900 1 300 10 60 10000" sets RDB save intervals, C disables RDB compression, D sets memory eviction policy.Final Answer:
CONFIG SET appendonly yes -> Option AQuick Check:
Enable AOF = appendonly yes [OK]
- Confusing RDB save command with AOF
- Using unrelated config commands
- Forgetting to set appendonly to yes
Solution
Step 1: Understand AOF with fsync everysec
With fsync set to 'everysec', Redis writes AOF data to disk every second.Step 2: Analyze durability implications
This means data could be lost if Redis crashes within the last second before fsync.Final Answer:
Data is saved only at intervals, risking data loss of last seconds -> Option AQuick Check:
AOF everysec fsync = possible 1-second data loss [OK]
- Assuming every write is immediately saved
- Thinking data is never saved automatically
- Confusing with no persistence
Solution
Step 1: Understand RDB and AOF coexistence
Redis supports both RDB and AOF, preferring to load AOF first on restart if available.Step 2: Analyze data loss causes
With both enabled, if data is missing after a crash, the most likely cause is AOF corruption, causing fallback to the older RDB snapshot and loss of recent changes.Final Answer:
AOF file is corrupted and Redis cannot load it -> Option DQuick Check:
Data loss with both = AOF corrupted [OK]
- Believing Redis can't use both persistences
- Thinking RDB interval too long is the cause
- Forgetting to restart Redis
Solution
Step 1: Match recovery speed and data loss tolerance
RDB snapshots every 60 seconds allow fast recovery but may lose up to 1 minute of data.Step 2: Compare with AOF options
AOF with fsync always is slower but safer; both enabled adds overhead; disabling persistence risks total data loss.Final Answer:
Enable RDB snapshots every 60 seconds, disable AOF -> Option CQuick Check:
Fast recovery + 1 min loss = RDB every 60s [OK]
- Choosing AOF for fast recovery despite slower startup
- Enabling both causing unnecessary overhead
- Disabling persistence risking total data loss
Ready to prove it?
Pass the test and this pattern moves unknown
