Redis vs. Aerospike: When to Use Each for Low-Latency Java Workloads

Redis and Aerospike are rarely a straight swap, and the question most teams are actually asking is not which one is faster. Both answer a point read in well under a millisecond, and the gap between them is usually smaller than the network in front of them. What separates them is how much of your application you have to write yourself — and, once you look at the free editions, what each one costs to run.

Aerospike is a shared-nothing distributed database written in C that keeps its index in RAM and its records on flash, which lets one node hold far more data than it has memory. Redis — or Valkey, the BSD-licensed fork most cloud providers now default to, and the source of the performance figures below — is an in-memory data store whose values are data structures with atomic operations over them. That difference propagates up into your Java code and lands somewhere neither vendor's comparison page goes.

Search Redis vs Aerospike and Aerospike itself holds two of the top ten results, including the first. Neither of its pages contains a line of Java, a benchmark number you can check, or a word about what the free edition actually gives you. This article covers those three.

What Aerospike Is, and What Redis Is

Aerospike is a distributed NoSQL key-value store, open-sourced under AGPLv3 in June 2014 and sold commercially alongside it. Its defining choice is the hybrid memory model: primary indexes live entirely in RAM while records live on SSD or NVMe. Data is organised into namespaces, which are also the unit of storage and retention configuration; a record is addressed by key and holds named bins. Every operation on a single record is ACID. Clients are "smart," holding a partition map of the cluster and routing each request straight to the node that owns the data.

Redis keeps its working set in memory and persists asynchronously. Its values are not opaque blobs but data structures — strings, hashes, lists, sets, sorted sets, streams, bitmaps, HyperLogLogs, JSON documents, vector sets — each with atomic commands that execute on the server, where the data already is. Their Java equivalents map one to one. It has no relational tables and no SQL query planner. In cluster mode the keyspace is divided into 16,384 hash slots spread across shards — partitioning by a fixed slot count rather than by consistent hashing — and the client routes by slot.

On consistency they are not symmetrical, and this is the one place Aerospike's marketing has a point that survives scrutiny. Aerospike has a genuine strong-consistency mode. Redis Cluster does not guarantee strong consistency at all; WAIT and WAITAOF bound how many replicas acknowledged a write, which is not the same thing.

Where Aerospike Genuinely Wins

Flash economics at multi-terabyte scale

Holding a 20 TB dataset in Redis means buying 20 TB of RAM, which at any cloud provider is the dominant line item in the bill. Aerospike holds the same dataset with only its primary index in memory. Its own capacity guide puts that index at 64 bytes per record multiplied by the replication factor: a billion records need roughly 64 GB of index at RF 1, or about 128 GB cluster-wide at the default RF 2, rather than however many terabytes the values occupy. Those live on NVMe. This is arithmetic rather than positioning, and it is why Aerospike shows up in adtech bidders and telco subscriber stores where the dataset is enormous and each record is read rarely.

Predictable tail latency at high density

Because Aerospike was designed around flash from the start rather than treating disk as a persistence side-channel, it does not have Redis's fork-based snapshot behaviour, and a node holding a very large dataset behaves much like a node holding a small one. If your service is judged on p99 rather than mean — and most low-latency services are, which is why tail latency is the metric that matters — that stability at density is a real argument.

Multi-record transactions and purpose-built XDR

Aerospike 8.0, announced February 2025, added multi-record transactions, and cross-datacenter replication is a first-class, long-standing feature rather than something assembled from replication plus tooling. If you need transactional writes across several records, or active-active replication between regions as a product capability rather than a project, that is a genuine difference. Read the licence section before you count on either: both are commercial features, and multi-record transactions sit behind additional licensing even within Enterprise.

If the dataset is very large, mostly cold, accessed by key, and the cost of RAM is the thing keeping you awake, Aerospike is the better fit and you should pick it.

What "Single-Threaded" Actually Means in 2026

Aerospike's comparison page describes Redis as a "single threaded data structure server" that requires "separate child processes for cluster proxy, persistence, replication," creating "processing overhead and latency." The first half is wrong and the second is half right — and the page's own expandable detail already concedes "separate I/O threads for networking," so it is the headline that misleads, not the fine print.

Single-threaded execution is not single-threaded I/O

Redis executes commands on one thread deliberately: it is what makes every operation atomic without a lock, and what makes reasoning about concurrency tractable. Everything around that — socket polling, reading, parsing, writing — is threaded, and has been since Redis added io-threads in 6.0. Valkey 8.0 rebuilt that into an asynchronous design, and Valkey 9.1.0, released 19 May 2026, redesigned the threading communication model again for up to a further 17% throughput.

The published figures for the 8.0 work are specific. Measured against Valkey 7.2 on an AWS c7g.16xlarge with 8 I/O threads, 3M keys and 512-byte values, throughput rose from 360K to 1.19M requests per second, with average latency falling from 1.792 ms to 0.542 ms. Read those with their conditions attached: the workload was 650 clients issuing sequential SET commands, and Valkey notes the numbers also include a prefetch optimisation rather than the threading work alone. Valkey puts 9.1.0 at 2.1M requests per second with 512-byte payloads, 9 I/O threads and a pipeline depth of 10 — a pipelined workload, so not comparable with the figure above.

A single command thread does still mean one core's worth of command execution per shard. The answer to that is sharding, which is what Redis Cluster exists for, and it is the same answer Aerospike gives — add nodes.

There is no cluster proxy

Open-source Redis Cluster and Valkey have no proxy process. The client is cluster-aware: it fetches the slot map, caches it, and sends each command directly to the shard that owns the key, following MOVED and ASK redirects when the topology changes. That is architecturally the same design as Aerospike's smart client, and it is what any modern Java client does — see connecting to a Redis cluster in Java. The description of a proxy plus helper processes fits a Redis Enterprise deployment, not the software most readers are evaluating.

Persistence is the fair criticism

Redis's RDB snapshots do fork, and on a large instance that fork has a cost; AOF rewriting has its own. Aerospike writes durably in the write path instead. That is a real architectural advantage, and if you want the detail, Redis persistence covers what each mode actually guarantees.

The Licence and Edition Trap

Aerospike's comparison page contrasts its editions — "Every Aerospike edition runs the same core engine, developer API, license, and release roadmap" — against Redis's fragmentation across open-source and proprietary versions. It is a good argument and it deserves to be checked, because the free edition is capped in ways that change the comparison entirely.

The caps go further than the table suggests. Aerospike's limitations reference adds a maximum of two namespaces per Community cluster, no TLS, no access-control lists and no durable deletes.

The feature Aerospike beats Redis with is not in the free edition

The headline criticism on that comparison page is that Redis is "high-availability (AP) oriented, without guaranteed strong consistency in cluster mode." Aerospike's strong-consistency mode is Enterprise, behind additional licensing. Compared like for like — free against free — both systems are AP: available and partition-tolerant, giving up strong consistency, which is the trade the CAP theorem describes. The argument evaporates. It reappears only once you are paying, at which point it should be weighed against what else that money buys.

AGPL to AGPL is a sideways move

Redis 8 is tri-licensed under RSALv2, SSPLv1 and AGPLv3. Aerospike Community is AGPLv3 — the same copyleft licence, with an 8-node and 2.5 TB ceiling on top of it. If the AGPL is what your legal team objects to, Aerospike Community does not solve it. Valkey is BSD-3-Clause with no cap and no per-terabyte licence, and moving to it from Redis needs no application rewrite at all — see migrating from Redis to Valkey in Java, and Valkey vs Redis for how the two engines have diverged since the fork. We make the same argument about source-available licences generally in Redis alternatives: changing engines to escape a licence only works if the destination licence is actually different.

None of this means Aerospike Enterprise is bad value. It buys strong consistency, XDR, encryption and rack awareness in one supported product, and for a team that needs all four the alternative is assembling them. The point is narrower: the comparison worth running is Aerospike Enterprise against Valkey, because the free tiers are not comparable in the way the marketing implies.

Records vs. Data Structures

The value model is the difference easiest to see in code, so start there.

Suppose you keep a leaderboard. In Redis it is a sorted set: ZADD to record a score, ZREVRANGE to read the top hundred, ZINCRBY to bump one, ZREVRANK to find a player's position. Each is a single atomic command executing on the server, and the top-hundred read never transfers the other million entries across the network. We build the whole thing in building a real-time leaderboard in Java.

Aerospike has ordered maps and lists as collection data types inside a bin, and its operate call applies list and map operations server-side, so a bounded leaderboard held in one record works and works well. The constraint is the record: collection operations take a single key, and a leaderboard that outgrows one record has to be partitioned by your application. Redis's sorted set is a top-level keyspace object with no such boundary, and cross-key structure is what its command set is built around.

Expiry differs in the same direction. Aerospike TTL is per-record. Redis TTL is per-key, and Redisson's RMapCache pushes it further down still, giving each entry inside a map its own time-to-live and max-idle. If you cache entities whose freshness requirements differ per entity, that removes a whole class of bookkeeping.

Neither model is better in the abstract. If your access pattern is "fetch this record by key, update some of its fields," Aerospike's model fits it exactly and its storage engine is the better one. If your access pattern involves ranking, set algebra, fan-out, sliding windows, approximate cardinality or anything else that wants an operation rather than a fetch, you will be writing that logic in Java against Aerospike and calling a command against Redis. The full set, and how each maps into Java, is in Redis data types.

The Java Layer Is Where This Is Decided

What the Aerospike Java client offers

Here is the shape of IAerospikeClient, the Aerospike Java client's main interface:

put, get, getHeader, exists, delete, touch, touched, add, append, prepend, operate, scanAll, scanNode, scanPartitions, query, queryNode, queryPartitions, queryAggregate, execute, createIndex, dropIndex, truncate, commit, abort, info, batch variants of the read and write calls, UDF registration and removal, plus cluster, metrics and administration accessors.

That is a well-designed data-access client and it does its job. What it is not is an application framework. Search the same file for lock, semaphore, countDownLatch, blockingQueue or rateLimiter and the only matches are in Javadoc prose — "this call will block until the scan is complete," "in order to prevent deadlock." There is not one distributed coordination primitive in the Aerospike Java client.

Locks, semaphores and rate limiters

You can build a lock on Aerospike. People do: a conditional write on a record with a generation check, a TTL for the lease, and a renewal loop. The lease semantics, the renewal, the reentrancy, the fencing token and the behaviour when the holder dies mid-operation are all yours to get right, and getting them right is a well-known way to lose a week. Redisson ships them:

RedissonClient redisson = Redisson.create(config);

// Watchdog: a lock taken without an explicit lease time is held for 30s
// and renewed every 10s for as long as this JVM is alive. If the JVM
// dies, the lease simply expires - no stuck lock, no manual cleanup.
RLock lock = redisson.getLock("order:" + orderId);
lock.lock();
try {
    processOrder(orderId);
} finally {
    lock.unlock();
}

// When a slow holder must not be able to corrupt state after its lease
// expires, take a fenced lock and pass the token to the resource.
RFencedLock fenced = redisson.getFencedLock("ledger:" + accountId);
Long token = fenced.lockAndGetToken();
try {
    ledger.append(accountId, entry, token);   // stale token is rejected
} finally {
    fenced.unlock();
}

The same pattern repeats across everything a distributed Java service needs and neither storage layer ships: RSemaphore and RPermitExpirableSemaphore for bounded concurrency, RCountDownLatch for start barriers, RRateLimiter for distributed rate limiting, RBlockingQueue for work distribution. Where java.util.concurrent has a matching interface, Redisson implements it: RLock is a Lock, RBlockingQueue is a BlockingQueue, RMap is a ConcurrentMap. That is the point of a distributed lock library, and using Redis locks in Java covers the failure modes.

Near cache: no network call at all

Caching is the second gap, and the larger one for latency. RMapCache adds per-entry TTL to a map; on Valkey 9.0+ or Redis 7.4+ prefer RMapCacheNative, which leans on server-side hash-field expiry — reach for the classic RMapCache when you need max-idle eviction, as the example below does. RLocalCachedMap keeps a copy of hot entries inside the JVM, invalidated across the cluster by pub/sub — a near cache:

// Import org.redisson.api.options.LocalCachedMapOptions - the identically
// named org.redisson.api.LocalCachedMapOptions is deprecated and has no
// name() factory, so an IDE auto-import lands on the wrong class.

// Per-entry TTL and max-idle inside one map - not available with a
// whole-record TTL model.
RMapCache<String, Product> catalog = redisson.getMapCache("catalog");
catalog.put(sku, product, 10, TimeUnit.MINUTES, 2, TimeUnit.MINUTES);

// A separate map, shown for contrast. Near cache: hits are served from
// local memory and never leave the JVM.
// Writes anywhere in the cluster invalidate the local copy over pub/sub,
// so readers do not serve stale data.
LocalCachedMapOptions<String, Product> options =
    LocalCachedMapOptions.<String, Product>name("catalog-near")
        .cacheSize(10_000)
        .evictionPolicy(LocalCachedMapOptions.EvictionPolicy.LRU)
        .syncStrategy(LocalCachedMapOptions.SyncStrategy.INVALIDATE);

RLocalCachedMap<String, Product> near = redisson.getLocalCachedMap(options);
Product p = near.get(sku);   // no network call on a hit

Aerospike has no client-side cache. Every read is a network round trip, however fast the server answers it. For a genuinely hot key read thousands of times a second, a near-cache hit is a memory access measured in nanoseconds against a round trip measured in hundreds of microseconds — three orders of magnitude, and the largest single latency difference available in this comparison. Distributed caching in Java covers the invalidation strategies, and JSON client-side caching does the same for JSON documents.

JCache, Spring Cache, Spring Session, Hibernate

Redisson is a JCache (JSR-107) provider, a Spring Cache manager, a Spring Session store and a Hibernate second-level cache, so @Cacheable works, @EnableRedisHttpSession works, and the Hibernate region factory is a configuration property — see the Spring Boot caching guide and JCache on Valkey and Redis. Aerospike covers one of the four: Spring Data Aerospike, which Aerospike maintains, ships an AerospikeCacheManager, so @Cacheable does work against it. There is no JCache provider and no Hibernate region factory, and the community Spring Session module has seen almost no activity — those you would write or do without.

What Aerospike and Redis Actually Cost

Both sides quote total cost of ownership and neither shows its working, so here is the shape of the trade.

Aerospike Enterprise is licensed by volume of unique data managed and by number of active production clusters — a cost that grows with your business, charged on top of the hardware. Against it, the flash model means fewer and cheaper machines. Redis and Valkey have no per-terabyte licence — you pay for instances, or for serverless capacity on a managed service — but you pay for enough RAM to hold everything you want to serve.

Where the crossover sits

Below a terabyte or so, RAM is affordable and the Aerospike licence is pure addition, so Redis or Valkey is cheaper. At tens of terabytes of mostly cold, key-addressed data, the hardware saving from flash can exceed the licence and Aerospike is cheaper even after paying for it. In between it depends on your working-set ratio — how much of that data is actually read — and that is a number only you have.

The adjustment people forget is engineering. If picking Aerospike means writing your own lock, your own near cache, your own JCache bridge and your own Hibernate integration, that is a real recurring cost set against a licence fee, and it is the one that never appears on a TCO slide.

Running Both: Aerospike Below, Redis Above

The framing that resolves most of these comparisons is that the two are not alternatives at all. If Aerospike's storage economics fit your dataset, use it as the system of record and put Redis or Valkey alongside it for the state that is not a cache of anything in Aerospike. That state is larger than people expect:

• Locks and leases
• Rate-limit windows
• Sessions
• Leaderboards and rankings
• Job queues and delayed queues
• Pub/sub fan-out
• Idempotency keys and feature-flag snapshots
• Aggregates expensive to compute and cheap to lose

None of these is a durable record, all of them are wanted in microseconds, and every one is a data-structure operation rather than a record fetch. Reads then go through the cache and writes go behind it: Redisson's MapLoader and MapWriter let an RMap load from the Aerospike store on a miss and flush to it asynchronously, which removes the cache-aside and write-behind plumbing from your service layer entirely. It is the same shape we describe for DynamoDB and MongoDB.

The inversion — whether Redis can be the system of record and the other store dropped — has a different answer, and we cover it in using Valkey or Redis as a primary database in Java.

Aerospike or Redis? A Decision Rule

Six cases cover almost every real evaluation.

If you are running the evaluation now, the most useful thing you can do is stop comparing single-operation server latency, because both will satisfy you. Compare instead what your dataset costs to hold in each, and count how many lines of coordination and caching code you would have to write and then maintain — the patterns in ten Redis use cases built in Java are a fair inventory of what that means. Those two numbers decide it, and only one of them appears on a benchmark chart.

Frequently Asked Questions

Why is Aerospike better than Redis?

For one specific shape of workload it is: very large datasets, addressed by key, where most records are read rarely. Aerospike keeps only the index in RAM and the records on NVMe, so it holds tens of terabytes on far fewer machines than an all-RAM tier, and it stays predictable at that density. It is not better for workloads built on ranking, fan-out, streams or set operations, it ships no coordination primitives in its Java client, and its free edition is capped in ways covered below.

Is Aerospike faster than Redis?

Not meaningfully, for a single operation. Both are one network hop and both answer a point read well under a millisecond, so the difference is smaller than your network. Aerospike's advantage is holding latency steady when one node holds a very large dataset. Redis has an advantage the benchmarks miss: with a near cache such as Redisson's RLocalCachedMap, a hot read is served from JVM memory with no network call at all, which is roughly three orders of magnitude faster than any round trip either server can answer. The "single-threaded" framing describes command execution only; I/O has been threaded since Redis 6.0.

Is Aerospike SQL or NoSQL?

NoSQL. It is a distributed key-value store: records are addressed by key within a namespace and hold named bins, with list and map collection types inside a bin. It offers secondary indexes and a query API, and real SQL is available for analytics through Aerospike SQL, a Trino-based Enterprise connector, but the primary access model is key-value, not relational. There are no joins and no query planner in the relational sense.

Who are the main competitors of Redis?

Valkey is the closest, being a BSD-3 fork of Redis 7.2 that most cloud providers now default to, and it is protocol-compatible so no application code changes. Beyond it: Memcached for pure caching, Dragonfly and KeyDB as performance-focused reimplementations, Hazelcast and Apache Ignite in the Java data-grid space, and Aerospike, ScyllaDB and Couchbase where the dataset is too large to hold in RAM. Which one is relevant depends on whether your problem is licensing, performance, cost or capacity, and we work through that in our guide to Redis alternatives. Teams searching the other direction, for Aerospike alternatives, usually land on the same shortlist.

Is Aerospike free?

Aerospike Community Edition is free under AGPLv3, but capped: up to 8 nodes and 2.5 TB of data, with no strong consistency, no multi-record transactions, no cross-datacenter replication, no compression, no encryption at rest, no rack awareness and no fast restart, plus a two-namespace limit and no TLS or access-control lists. Those are Enterprise features, several of them behind additional licensing on top of the Enterprise licence itself. Enterprise is priced by the volume of unique data managed and the number of active production clusters. Note that Community is AGPLv3, the same copyleft licence some teams leave Redis to avoid, so it is not an escape from that particular problem; Valkey is BSD-3-Clause with no node or data cap.

Can I use Aerospike from Java like I use Redisson?

No. The Aerospike Java client is a data-access client: put, get, operate, batch, scan, query, UDF execution and administration. It has no distributed locks, semaphores, latches, rate limiters or blocking queues, no java.util.concurrent implementations and no client-side cache. Spring Data Aerospike does add a Spring CacheManager, so @Cacheable works, but there is no JCache provider and no Hibernate second-level cache. Redisson provides all of it, so an RMap is a ConcurrentMap and an RLock is a Lock. Choosing Aerospike means writing the coordination and near-cache layer yourself or doing without it.

Does Netflix use Redis?

Netflix has publicly described both EVCache, its Memcached-based caching layer, and Dynomite, an open-source layer that added replication and sharding around Redis. The pattern worth taking from it is not the brand choice but the plurality: large engineering organisations run several data stores side by side, splitting key-value fetches from data-structure operations, which is exactly the split this article describes.