When Does Redis Need Faster Storage? A Guide to AOF Latency

Short answer: Redis keeps its working data in memory, but persistence can put storage in the latency and recovery path. Faster block storage matters when Redis AOF (Append Only File) writes, rewrites or restart time constrain the service. In Nirvana's 100,000-task read benchmark, Redis p99 was 68.0 ms on ABS versus 70.4 ms on io2-64k. That 3% difference is positive but small, so it should be treated as a workload result rather than a universal Redis ranking.

Why does an in-memory database care about disk?

Redis serves commands from memory, but durable configurations still write data to storage. The append-only file records operations so Redis can reconstruct state after a restart. Background AOF rewrites compact that history into a smaller representation.

If Redis is acting only as a disposable cache, storage may not control request latency. If it holds agent state, sessions, queues or other data that must survive a restart, the persistence and recovery paths deserve their own service objectives.

Which AOF policy are you running?

Policy	Disk behavior	Operational trade-off
appendfsync always	Fsync after appended commands	Strongest acknowledgement path, highest write cost
appendfsync everysec	Fsync approximately every second	Redis default; balances speed and possible recent data loss
appendfsync no	Operating system controls flushing	Lowest direct fsync pressure, larger durability window

The Redis persistence documentation recommends everysec as the usual balance. Do not compare platforms with different policies and call the result a storage win.

What did the benchmark show?

Nirvana's LangChain read benchmark ran Qdrant, Redis and PostgreSQL together on identical 4-vCPU, 16-GB machines with 256-GB volumes. At 1,000 agents completing 100 tasks each, Redis read p99 was 68.0 ms on ABS and 70.4 ms on io2-64k. The difference was 2.4 ms, or about 3%.

The same run recorded a clear Qdrant loss for ABS: 301 ms versus 140 ms on io2-64k. The full workload still finished in 58 minutes on ABS versus 69 minutes on io2-64k, but that compound result includes six operations across three services. It cannot be presented as a standalone Redis throughput result.

The write-path suite used appendonly yes with the default everysec policy. Its headline completion result covered the combined PostgreSQL, Redis and Qdrant checkpoint cycle, not Redis alone.

When is storage really the bottleneck?

Look for latency spikes during AOF rewrite, growing disk queues, slow restart or replica recovery, and persistence falling behind the write rate. Track Redis command latency beside storage latency and rewrite activity. If commands slow while disk remains quiet, the cause is elsewhere.

Memory capacity, single-threaded command execution, large keys, client behavior and network placement can dominate first. A higher IOPS ceiling cannot fix those constraints.

How should you test Redis infrastructure?

Use the production dataset, command mix, pipeline depth and client count. Keep AOF and rewrite settings identical. Run long enough to include at least one rewrite and then test restart or recovery from the persisted state. Measure command p99, rewrite duration, storage queueing, time to accept traffic and time to restore the expected hit rate.

Use the published benchmark as evidence for one multi-service agent workload, then bring your Redis workload for a matched evaluation.

FAQ

Is Redis always memory-bound?

No. Command execution may be memory- or CPU-bound while persistence, rewrites and recovery still depend on storage.

Does faster storage make every GET faster?

No. A cache hit served from memory may not touch disk. Measure the path that is actually slow.

Should I use appendfsync always?

Only when its durability behavior matches the application requirement. Redis documents a much higher performance cost than everysec.

Does the benchmark prove Nirvana is the fastest Redis infrastructure?

No. It shows a small Redis p99 lead inside one sustained, multi-service agent workload. A Redis-specific claim needs a dedicated test covering persistence, rewrites and recovery.

---

About Nirvana Labs

Nirvana Labs is a high-performance storage cloud purpose built for blockchain, AI and databases i.e. the most demanding, real-time, stateful workloads. Accelerated Block Storage (ABS) offers 20K baseline IOPS included, no over provisioning. Nirvana Kubernetes Service (NKS) with Karpenter auto-scaling, high clock-speed compute and private networking. Backed by Jump Trading, Crucible, etc with 50+ customers live in production today.

Learn more at Nirvana Labs

Nirvana Cloud | Pricing | Blog | Docs | Changelog | LinkedIn | Twitter | Telegram | YouTube