Benchmark
Aerospike vs. Redis: A benchmark across four configurations
Key highlights
In its default durable mode (HMA), Aerospike matched its own in-memory performance as long as the working set fit in memory.
In both configurations where records were served from RAM, Aerospike was not only faster than Redis but steadier. Its latency showed far less jitter, and it held the throughput it was asked for far more reliably.
With caching switched off, forcing Aerospike to serve every request straight from disk, it still matched in-memory latency and held it steadier than Redis. The only thing it gave up was peak throughput.
Aerospike held its performance even after the dataset grew tenfold on the same hardware, beyond what memory could hold, showing the behaviour holds at scale rather than only on a small dataset.
What you'll learn
This benchmark, conducted and measured by McKnight Consulting Group, runs Redis and Aerospike under a uniform 90/10 read/update workload and steps Aerospike through four progressively harder configurations:
In memory: matching Redis exactly on the same hardware and data.
Durable: persisting a copy of every record to disk so a lost node no longer means lost data.
From disk: serving every request straight from storage with caching switched off.
From disk, at 10x the data: growing the dataset tenfold on the same four nodes.
The benchmark is built to test a common assumption: that keeping data in memory is essential for the lowest possible latency. The intuition compares RAM to disk in isolation, but that isn't the comparison that matters. What dominates a real request is the network trip to the cluster, and against that, the difference between a memory read and a local disk read is small enough to disappear.
There is a trade-off, though: peak throughput from disk cannot match what memory delivers. A disk moves fewer bytes per second than RAM, so the ceiling on operations per second is lower, even though any single request is barely affected.
Key highlights
In its default durable mode (HMA), Aerospike matched its own in-memory performance as long as the working set fit in memory.
In both configurations where records were served from RAM, Aerospike was not only faster than Redis but steadier. Its latency showed far less jitter, and it held the throughput it was asked for far more reliably.
With caching switched off, forcing Aerospike to serve every request straight from disk, it still matched in-memory latency and held it steadier than Redis. The only thing it gave up was peak throughput.
Aerospike held its performance even after the dataset grew tenfold on the same hardware, beyond what memory could hold, showing the behaviour holds at scale rather than only on a small dataset.