Redis vs. Aerospike

Redis, Inc. (formerly Redis Labs / Redis Ltd.) is the main company behind Redis.

• Redis Open Source is offered under a tri-license (RSALv2, SSPLv1, or AGPLv3) and folds the former Stack modules (JSON, Time Series, Query Engine, Vector Sets, and more) into the core.

• Redis Software (still widely known by its former name, Redis Enterprise) is Redis, Inc.'s flagship commercial engine. It layers in a management and proxy tier, and active-active geo-distribution.

• Redis Cloud is a fully managed service delivering those same capabilities.

Valkey is a BSD-licensed fork of an earlier version of Redis Open Source, with its own development since the fork. It is now the default open-source engine on most managed clouds.

Around these sit the wire-protocol-compatible cloud services from the major hyperscalers.

• Amazon ElastiCache offers a choice of engine, Redis or Valkey.

• Google Cloud Memorystore offers a choice of engine, Redis or Valkey.

• Azure Managed Redis is built on Redis Software, so it inherits the commercial engine's capabilities (and its drawbacks) rather than those of the open-source engines.

Aerospike Community Edition (CE) is a free, AGPLv3 offering, well suited to evaluation and smaller deployments, but it omits many enterprise capabilities (Cross Datacenter Replication and multi-site clustering, strong-consistency mode, rack awareness, multi-record transactions, encryption at rest, role-based access control, and change notification), caps usage, and has only community support.

Aerospike Enterprise Edition (EE) adds those capabilities and includes production support.

Aerospike Cloud, available on AWS and planned for Google Cloud and Microsoft Azure, delivers Aerospike EE as a fully managed service. In the sections below, Aerospike Enterprise Edition and Aerospike Cloud (the most commonly used editions) will be discussed as the default. Aerospike CE will be called out separately where it differs.

Redis and its variants were designed first and foremost as an in-memory store. Command execution on a shard is single-threaded with separate I/O threads for networking. Durability is not intrinsic: persistence via RDB (Redis Database, periodic snapshots of the whole dataset) or AOF (Append Only File, a log of every write command), mechanisms common to Redis. Capacity is bounded by how much RAM you can afford. Where support for NVMe-backed storage has been added, it is a bolt-on and severely compromises latency and throughput.

A single storage model supports all-RAM, all-NVMe, or hybrid configurations. In NVMe configurations, Aerospike accesses disk as a raw block device and is heavily multi-threaded, so a single process saturates all cores. The write path is purpose-built for how NVMe writes (coalescing writes into large sequential blocks), and defragmentation runs continuously as part of that write path, so steady-state performance stays predictable under sustained load. Aerospike capacity scales with cheaper storage, durability is intrinsic, and the same system can serve as both cache and system of record.

Primary access pattern is key-value, with value types including strings, hashes, lists, sets, sorted sets, streams, bitmaps, bitfields, HyperLogLog, and geospatial.

Secondary indexing approaches are fractured across the variants. Redis Software, Redis Cloud, and Azure Managed Redis use the Redis Query Engine (formerly Redis Search module) for declarative indexing of hash fields, including indexing of elements in list structures. Other variants lack declarative secondary indexes and rely on manually maintaining additional data structures (lists or sets) to serve as indexes.

Different variants have also added support for specialty data types and functionality. These include hybrid and full-text search, JSON, time series, vector, and a variety of probabilistic data structures. Many of these were formerly "modules" available under a separate license, but are now folded into the Redis Software, Redis Cloud, and Azure Managed Redis products. Many modules are lacking in other Redis variants and, when available, they may not be one hundred percent compatible.

Primary access pattern is key-value, with value types including string, integer, double, blob/byte, boolean, lists (ordered or unordered), and maps (unordered, key-ordered, or value-ordered), HyperLogLog, and geospatial.

Aerospike allows multiple different data types to be stored under a single key using separate bins (analogous to columns in relational databases), providing additional flexibility.

Aerospike supports declarative secondary indexing on individual bins or on entries in a list or map.

Each Redis variant is widely used for caching. In-memory performance and simple TTL-based expiry with approximate LRU/LFU eviction make it a natural, well-understood fit that is easy to adopt. The RAM-first design means that caching large datasets is prohibitively expensive, and the variants that offer NVMe storage options suffer from decreased performance.

Aerospike can act as a high-speed cache or a persistent real-time platform. Per-record TTL-based expiry and LRU eviction at the set or namespace level are easy to configure. Options for storing data all in RAM, all in NVMe, or in a hybrid fashion allow for system design that balances cost, data size, throughput, and latency requirements. Optimized NVMe support allows for very large datasets in cache without sacrificing latency.

A single Redis instance is a standalone process. To form a cluster, the keyspace is partitioned across hash slots spread over many shard processes, and high availability requires replicas plus a quorum of primaries to promote on failure, so a fault-tolerant deployment needs several nodes and careful replica placement. That placement is the operator's job when self-managed, and it's automated in the managed services. Scaling out or in migrates hash slots (and the keys inside them) between shards while live traffic continues, so rebalancing competes with the workload.

A consequence that catches many teams off guard is that a clustered Redis is not the same database as a non-clustered one, and this holds across every variant. Because data is partitioned across slots, multi-key operations (MGET, MSET, cross-key set operations, multi-key transactions, and Lua scripts) only work when the keys share a slot, and otherwise return CROSSSLOT errors. Working around this means pinning keys with hash tags or redesigning access patterns, so moving between non-clustered and clustered modes is not a transparent config change, and it can force real application rework.

The two clustering models diverge most on scaling and recovery.

Scaling a Redis cluster means adding shard processes and resharding, which competes with live traffic while it runs. Because a clustered Redis is not the same database as a non-clustered one, that move can also force application rework rather than being a transparent change. Aerospike scales by migrating only the partitions that must move while the cluster keeps serving, and the application behaves identically at any cluster size, so growth does not entail resharding chores or code changes.

Recovery follows the same pattern of contrast. Promoting a new primary in a Redis cluster requires the gossip protocol to detect the failure and a quorum of the remaining primaries to vote on the promotion. Aerospike's Smart Client already holds a live partition map, so on a node failure it computes the new owner of an affected partition directly, without waiting on cluster-wide consensus.

Finally, because each Aerospike node is able to handle more traffic than the single-threaded Redis process, there are far fewer nodes in an Aerospike cluster, reducing cost and complexity.

Durability is optional and bolted on, and the mechanics force a trade-off between data safety and throughput. RDB takes point-in-time snapshots at intervals, so a node failure loses every write since the last snapshot. AOF logs each write command, with an fsync policy that sets the exposure: always fsyncs every write (safest, but a large throughput and latency cost), everysec fsyncs once per second (the common default, risking up to a second of writes), and no leaves flushing to the OS (fastest, least safe). Even AOF's strongest setting is a durability-versus-performance dial rather than a guarantee. NVMe-enabled variants cannot use their NVMe storage for persistence or recovery.

Rebuilding a large in-memory dataset from disk on restart is also slow, since the whole dataset must be replayed or reloaded before the node can serve traffic again.

A single engine covers all-RAM, all-NVMe, and hybrid configurations. In NVMe-based options, including hybrid, durability is a native property of the storage engine, not an add-on. Records are written to NVMe as part of the normal write path, and a write can be configured to commit to the device before it is acknowledged, so an acknowledged write survives a node restart or power loss, with no snapshot interval during which recent writes could be lost. On restart, a node comes back from its persisted data quickly rather than replaying a large log to rebuild an in-memory dataset.

Robust, battle-tested SDKs exist for essentially every mainstream language. Some SDKs are maintained by Redis, Inc., while others are community supported. Clients operating in cluster mode support a single hop to shards holding requested keys.

While Redis, Inc. controls the historically "official" clients (redis-py, node-redis, jedis), Valkey maintainers have introduced GLIDE, a separate official client line. The practical effect is that "use the standard Redis client" is no longer a single answer: teams increasingly must choose which client line to standardize on, which can subtly couple an application to one side of the fork.

Beyond basic CRUD capabilities, the Aerospike Smart Clients handle a great deal on the application's behalf: they track cluster state and refresh their partition map as nodes join, leave, or fail, transparently retry and fail over to a replica on timeouts or node loss, manage connection pooling and load balancing across the cluster, and honor policies such as rack-aware reads.

Coverage extends well beyond the officially supported set. PHP and Ruby have Aerospike-maintained, community-supported clients; Spring Data Aerospike provides an idiomatic Spring layer over the Java client; and community drivers exist for languages such as Elixir, Erlang, and Perl.

Because execution is single-threaded per shard, scaling up one instance has limited benefit; capacity comes from adding shards and redistributing slots. Redis, Valkey, and the managed services automate resharding to reduce disruption, but the scaling story is fundamentally "add more shard processes."

Aerospike distributes data across logical partitions evenly spread over nodes; adding or removing a node migrates only the partitions that must move, minimizing data movement. It also scales vertically by exploiting NVMe, multi-core CPUs, and fast networking, with a peer-to-peer architecture in which no node has a special role.

Redis replicates asynchronously by default. Redis's own documentation is explicit that Redis Cluster does not guarantee strong consistency, and under some failures, acknowledged writes can be lost.

Some variants (Redis Software, Redis Cloud, Azure Managed Redis) offer Conflict-Free Replicated Data Types (CRDTs), used primarily for geo-distribution, but these are also not strongly consistent. Not every type gets conflict-free, no-loss semantics, either: counters, sets, and per-field hash updates converge without loss, but Redis's own docs classify plain strings (and bitfields) as "non-conflict-free." Those types resolve by last-write-wins (LWW) on a wall-clock timestamp, silently dropping the losing write. Since strings are the most common Redis type (cached objects, session state, serialized JSON), the "nothing is lost" promise of CRDTs does not hold for the workloads most teams run.

Aerospike offers distinct AP and CP modes per namespace, and neither mode makes the usual hard trade-off implied by the CAP theorem (Consistency, Availability, Partition tolerance). Its AP mode still replicates quickly enough that the eventual-consistency window stays tight, well short of what teams typically brace for with an AP system. Its CP mode doesn't sacrifice availability to the degree many CP databases do, since consensus happens per partition rather than across the whole cluster, and read and write consistency levels are configurable rather than requiring every replica to acknowledge. Its strong-consistency mode was validated by Jepsen testing and prevents stale reads, dirty reads, and data loss.

Aerospike offers true distributed multi-record Atomicity, Consistency, Isolation, Durability (ACID) transactions that provide strict serializability, the strongest correctness guarantee available in a distributed database. Transactions spanning multiple records and their replicas execute as if in a single real-time order, preventing not only stale and dirty reads but subtler anomalies like causal reverse, where a later transaction's effects become visible without an earlier, causally related one also being visible. Few distributed databases, relational or NoSQL, offer this guarantee at all.

Redis variants diverge considerably here. All offer some form of active-passive replication, where a "follower" cluster can be established in a remote location that asynchronously receives the writes of a leader cluster. Redis Software, Redis Cloud, and Azure Managed Redis support Conflict-Free Replicated Data Types (CRDTs). Importantly, not every type gets conflict-free, no-loss semantics: counters, sets, and per-field hash updates converge without loss, but Redis's own docs classify plain strings (and bitfields) as "non-conflict-free," resolved by last-write-wins on a wall-clock timestamp, so the losing write is silently dropped. Since strings are the most common Redis type (cached objects, session state, serialized JSON), the "nothing is lost" promise of CRDTs does not hold for the workloads most teams run.

Aerospike offers two multi-site models with very different consistency characteristics.

The first is asynchronous active-active replication via Cross-Datacenter Replication (XDR), which supports star, one-way, and mesh topologies with filtered replication. Because each cluster accepts local writes and ships them asynchronously, the same record can be updated in more than one cluster before replication catches up, so conflicts are resolved by last-write-wins, either whole-record or, with bin convergence enabled, at the individual field level, so writes to different fields both survive.

Last-write-wins has an important limitation: it converges every copy to the same final state but does not preserve intermediate updates, and it depends on reasonably synchronized clocks. That makes XDR active-active a good fit where the latest value is what matters (session state, profiles, last-known location, and caches) and a poor fit where every update must be counted (wallets, ledgers, and inventory). Often the right fix is a data-modeling one: if you model changes additively in a Collection Data Type (appending each update rather than overwriting a value), concurrent updates land as distinct entries and the merged record accumulates every contribution, letting many "every update counts" workloads use async active-active safely.

The second model, synchronous active-active via multi-site clustering, forms one cluster spanning data centers and uses strong-consistency mode to prevent conflicts entirely, so no committed write is lost. The trade-off is the physics of synchronous replication: each write pays the inter-site round trip, so it needs low-latency (typically metro or regional) links, or a tolerance of higher latency for database writes.

The Redis wire protocol is one of the most widely supported in the industry, and Valkey is protocol-compatible, so most clients and tooling work across both. Connectors include ODBC/JDBC and SQL, Spark, and Trino integrations, and Redis Software and the managed services add first-party integrations (for example, Memorystore's LangChain integrations for generative AI applications).

Aerospike provides optimized connectors for Kafka, Spark, Presto/Trino, JMS, Pulsar, Event Stream Processing (ESP), Elasticsearch, LangChain, LangGraph, and others, giving analytics, AI, and event-processing tools broad access to Aerospike data.

Redis has no unified, built-in CDC mechanism. Keyspace notifications provide a lightweight event stream, but they're a best-effort notification, not a guaranteed delivery log, so consumers must code carefully to avoid lost events or duplicates. Redis Data Integration (RDI), available only for Redis Software, is the closer equivalent to a dedicated CDC product, streaming changes to external systems with stronger delivery guarantees. Valkey, ElastiCache, and Memorystore have no first-party equivalent to RDI, leaving keyspace notifications or third-party tooling as the main options.

Aerospike's change notification is not a bolt-on; it rides on the same components that power XDR, battle-tested in large global deployments. As records change, the engine publishes them through that replication path to Kafka, Pulsar, JMS, Elasticsearch, or any HTTP endpoint via Event Stream Processing (ESP). Capture is granular: rapid writes to a hot record are compacted to the latest version, and a change is acknowledged only once it has been delivered, so a downstream outage doesn't lose data.

Multi-tenancy in Redis relies on running separate instances (or databases, in Redis Software) to isolate tenants. Redis itself notes that customers with strict isolation needs may be better served by a single-tenant approach. Redis Software deserves specific scrutiny: even when tenants are split into distinct databases, a single shared proxy process on each node fronts all databases on that node. That shared proxy is a common point of contention and failure: a noisy tenant that saturates it can degrade every other database behind it, and a proxy fault affects them all, so the per-database boundary is undercut at the connection tier.

Within one cluster, Aerospike provides separate namespaces, role-based access control with sets, rate quotas, and per-set storage limits, practical tools for sharing infrastructure across tenants. This is soft multi-tenancy: it lets more tenants share the same cluster, but because they still share underlying resources, isolation is never as complete as giving each tenant dedicated hardware.

Where strict isolation matters, Aerospike's efficiency makes dedicated per-tenant clusters viable: it runs very well on modest hardware (nodes with as few as two vCPUs), so a fleet of small, fully isolated clusters is economically reasonable, unlike a RAM-bound, process-per-core engine.

Redis relies on keeping data in RAM. Execution is single-threaded per shard, with multi-threaded network I/O added in some variants. Full multi-core utilization still means running many instances per machine, and where NVMe support has been added, it severely impacts throughput and latency.

Massively multi-threaded within one process (throughput rises with core count instead of more processes); NVMe storage accessed as a raw block device, with cloud block storage and NAS also supported; Application Device Queues with supported NICs to cut context switching; and indexes (and optionally data) in RAM, with hybrid and all-NVMe layouts per namespace.