The best Redis alternatives for 2027

Most comparisons of Redis alternatives start with throughput, but throughput shouldn't be the first question. It sets node count, and node count determines costs, but what first determines whether a migration succeeds is what's constraining you in your current setup, and whether the candidate you pick is compatible with the data, commands, and operational assumptions you already have.

This guide compares the engines themselves, not the services that host them. Managed services, such as AWS ElastiCache, Microsoft Azure, and Google Cloud Memorystore, run several of these engines rather than replacing them, so they appear once, as an operational choice, under managed services.

Match the constraint to a candidate

Seven constraints recur frequently in Redis-alternative evaluations. The table below lists a candidate for each.

Check each of these against your workload. Here's what to test and what commonly breaks.

Two kinds of Redis alternatives

Systems that people group under "Redis alternatives" fall into two categories, divided by whether existing Redis clients can connect to them.

Redis-compatible engines have RESP (Redis Serialization Protocol)-compatible interfaces to connect existing Redis clients: Dragonfly, Garnet, KeyDB, and Valkey. Command coverage varies: Garnet, for example, implements most of the Redis API but not all of it. Moving to one of these uses the same wire protocol, but not necessarily command semantics, modules, scripting behavior, persistence formats, or operational behavior, however.

Systems with their own protocol use a different wire protocol and data model, so existing Redis clients can't connect, and adopting one is a rewrite, not a swap. Memcached is the narrowest: a simpler cache that covers one of Redis' use cases. Aerospike, Amazon DynamoDB, Apache Ignite, and Hazelcast are architectural replacements that solve different problems. The rewrite is sometimes worth paying for, but it should be recognized as a different class of decision. For some workloads, an architectural replacement can also take over the database behind the cache, which turns the comparison from one engine against another into two systems against one. That matters because it simplifies your stack: one system to operate, patch, and secure instead of two, one vendor relationship and support contract instead of two, and no cache-to-database synchronization (warming, invalidation, stampede protection) for your team to maintain.

Keeping these categories distinct matters because the evaluation criteria differ. For a Redis-compatible engine, the question is command and data compatibility. For a system with its own protocol, the question is whether its design fits the workload well enough to justify rewriting application code.

The Redis license timeline, and what's still unresolved

Redis changed its licensing twice in just over 13 months, and the second change added an option rather than reverting the first. That explains why many teams migrated and why the question is still open.

On March 20, 2024, Redis Ltd. moved Redis 7.4 and later from the BSD-3-Clause license to a dual model combining the Redis Source Available License v2 (RSALv2) and the Server Side Public License v1 (SSPLv1). Neither license is recognized as open source by the Open Source Initiative, and the change applies to all releases going forward.

Eight days later, on March 28, 2024, the Linux Foundation announced Valkey. Valkey forked from Redis 7.2.4, the last BSD-licensed release, and kept the BSD 3-clause license, with Google, AWS, Oracle, Ericsson, and Snap backing the project¹.

On May 1, 2025, Redis 8.0 added AGPLv3 as a third license option. Salvatore Sanfilippo, Redis' creator, wrote that Redis was open source software again under AGPLv3 terms². However, Redis 8 did not revert to BSD. Redis describes the current arrangement as a tri-license under which users may choose RSALv2, SSPLv1, or AGPLv3. RSALv2 and SSPLv1 remain on offer alongside the new option³.

The licensing timeline is therefore:

• Redis OSS 7.2 and earlier: BSD-3-Clause

• Redis 7.4–7.x: RSALv2 / SSPLv1

• Redis 8 and later (Redis Open Source): RSALv2 / SSPLv1 / AGPLv3 (tri-license)

First, AGPLv3 is OSI-approved open source, but it is also strong copyleft, and some organizations exclude it from their approved-license lists. "Open source again" does not necessarily mean "usable at your company."

Second, the 2024 change demonstrated that Redis Ltd.'s licensing strategy may change between releases. Redis Ltd. uses a contributor license agreement, and organizations concerned about future license stability should evaluate governance and contributor/IP arrangements separately from the license on offer today. That is a risk factor to assess, not a prediction about what Redis will do.

Four kinds of lock-in to evaluate separately

Lock-in is not one thing. A system can be excellent on one and poor on another, which is why one overall score is less useful than examining each independently.

License lock-in is whether the legal terms can change, and who decides that. The relevant facts are the license itself and the governance structure behind it.

Dragonfly's license file sets a change date of September 1, 2028, after which the licensed work converts to Apache 2.0⁴. Until then, the Additional Use Grant permits specified uses but restricts offering the software as a hosted or managed service of the kind defined in the license. Dragonfly documents this: The code is free to use and modify as long as you are not selling services built on it⁵.

An OSI-approved license is one way to limit license risk, not the only one. Many teams already run critical systems under commercial or proprietary terms, such as DynamoDB, managed caching services, and commercial database editions. There, the protection comes from the contract: pricing, support, an SLA, and exit terms. The question for each candidate is which kind of protection your organization's policy accepts.

API lock-in is how much application code depends on Redis-specific commands, modules, or scripting. A codebase using only strings, hashes, lists, sets, and sorted sets is generally the least difficult compatibility case, subject to command semantics and workload-specific testing. Transactions, scripting, expiration, blocking commands, replication, error behavior, and cluster semantics can all still differ. A codebase built on the Redis Query Engine or RedisJSON is a harder case.

Data-format lock-in is whether you can move persisted state directly. This is where the Redis 7.2/7.4 boundary is a limitation.

Operational lock-in is how much your high availability, backup, monitoring, and failover behavior depends on a specific vendor or managed service. Moving from self-managed Redis to a managed Valkey service reduces API lock-in while increasing operational lock-in.

Evaluating these separately produces a more useful answer than ranking systems by overall risk, because most organizations are constrained by only one or two of them.

Redis compatibility at a glance

*Valkey uses multi-threaded I/O but retains a primarily serialized command-execution model.

The main Redis alternatives

If you're considering migrating from Redis, here are more details about the primary alternatives.

Aerospike

Aerospike is a distributed database that stores record data on SSD/flash and keeps its primary index in memory, on persistent memory (PMem), or on flash, which makes large datasets less expensive. It is an architectural replacement rather than a Redis-compatible engine; it does not use the Redis protocol.

• Aerospike's patented Hybrid Memory Architecture is designed to deliver memory-like latency at SSD cost. Latency doesn't depend on whether a particular record was recently accessed, which is something a cache-dependent architecture can't say.

• Aerospike's strong consistency mode guarantees that successfully committed writes are not lost because of cluster partitioning, with a specific, documented exception: The guarantee does not hold if a cluster node's Aerospike process pauses for more than 27 seconds, or if clock skew between nodes exceeds 27 seconds. That's a threshold derived from the default heartbeat interval and timeout, and adjustable if those defaults change.

• Reads can be configured per operation for session consistency or global linearizability. Linearizable reads carry an extra cost on each read, so they suit reads where staleness would produce a wrong answer rather than every read.

• Since Aerospike Database 8, multi-record transactions are strictly serializable. They are opt-in and run as a separate layer with overhead of roughly four extra writes and an extra read, so ordinary single-record writes don't pay for them.

• For deployments that span sites, XDR replicates between clusters, and multi-site clustering runs one strong-consistency cluster across locations.

• Strong consistency mode is available in Aerospike Database Enterprise Edition and the Aerospike Cloud Managed Service.

However, adopting Aerospike means rewriting application code against Aerospike's client libraries. For a small cache that fits comfortably in memory and isn't causing problems, that cost is hard to justify, although running two systems has an ongoing cost even when neither is failing. The calculation changes when Aerospike can replace both the Redis cache and the database behind it, because the rewrite then removes a system rather than swapping one.

Best for: Datasets that significantly exceed affordable RAM where latency targets remain strict, workloads where a stale read produces an incorrect result, and teams maintaining both a cache and a separate database for the same data.

Dragonfly

Dragonfly is a from-scratch reimplementation of the Redis API and Memcached API on a multi-threaded, shared-nothing architecture. DragonflyDB built it to remove the constraint that one Redis process executes commands on one core.

As published at the time of writing, Dragonfly's benchmarks report crossing 3.8 million queries per second on a c6gn.16xlarge instance, a 25x throughput comparison against one unclustered Redis process, with 99th-percentile latencies near one millisecond at peak⁶. (Check the repository directly, because vendor benchmark pages get revised.) The same benchmarks report Dragonfly using about 30% less memory than Redis at idle, with no visible memory growth during snapshotting. That memory efficiency reduces the memory capacity you need, although CPU, network, replication, persistence, and failover headroom may still determine instance size.

Three caveats apply:

1. The 25x figure compares Dragonfly with one Redis process on a 64-vCPU instance, a configuration that teams don't run on hardware that size; see Reading Dragonfly's 25x benchmark claim for how it compares with clustered Redis.

2. The license is BSL 1.1 rather than an OSI-approved open source license.

3. Dragonfly's sharded execution model requires application-specific compatibility testing for multi-key operations, scripting, and transactions; consult Dragonfly's command documentation for the specific semantic guarantees your scripts use. 

Best for: Workloads that have outgrown one Redis process where Redis Cluster isn't an option, such as applications whose multi-key operations span keys that can't share a hash slot, and where BSL terms are acceptable.

Garnet

Garnet is a RESP-compatible cache-store from Microsoft Research, built on .NET and licensed under MIT⁷. It supports tiered storage across memory and SSD or Azure Storage, cluster sharding, replication, and checkpointing, and it allows server-side extensions written in C#.

Microsoft Research describes Garnet as a research project and states that versions of Garnet have been deployed in real-world use cases at Microsoft, including the Windows & Web Experiences Platform, Azure Resource Manager, and Azure Resource Graph⁸. That is meaningful evidence of production use, and it is distinct from a conventional commercial support or SLA commitment. Because Garnet is a research project, Microsoft's production use of it does not by itself give outside buyers a support contract or SLA, so buyers should weigh those separately.

Garnet's limitations are in API support. It implements most of the Redis API but not all of it, so check your application against its command coverage. 

Best for: .NET teams that need RESP compatibility and a permissive license.

KeyDB

KeyDB is a multi-threaded fork of Redis. Its distinguishing features were multi-threaded command execution, active replication supporting multi-master writes, and flash storage for datasets larger than memory.

However, it is not clear whether the product is still being maintained. At the time of writing, KeyDB's latest tagged release is 6.3.4, published in October 2023⁹. Its lineage is based on the Redis 6.2 line, which means its RDB format differs from newer Redis versions. An October 2025 issue asks whether Snap has abandoned the project, noting the absence of major updates since roughly 2023; it remains open¹⁰. A separate open issue reports critical CVEs affecting the 6.3.4 image¹¹. The repository continues to receive community issues.

A permissive license does not by itself solve maintenance, security-patching, or support risk. Teams evaluating KeyDB should decide from the release and issue history.

Best for: Assessment by teams with existing KeyDB deployments; new deployments should weigh the maintenance evidence.

Memcached

Memcached has been in production since 2003 as a multi-threaded caching layer built around one data type: strings. Persistence, complex data structures, replication, and cluster mode are not included.

When a workload is purely a cache in front of a slower system of record, Memcached's fewer features are less work. There is less to tune and less to consider during an incident.

The limitation is equally clear. Memcached's default maximum item size is 1 MB, though the limit can be configured, and its values are opaque byte strings rather than Redis-style native data structures. In addition, a restart also loses the cache. Any workload using Redis as a queue, a structured session store, a leaderboard, or a pub/sub bus will not fit.

Best for: High-volume string caching where data loss on restart is acceptable.

Valkey

Valkey is a BSD-licensed fork of Redis 7.2.4, governed by the Linux Foundation, and it is the closest Redis-compatible alternative for deployments based on Redis OSS 7.2 and earlier, subject to feature and module compatibility. Because Valkey began as a copy of the Redis 7.2.4 source tree, it uses the same RESP wire protocol, accepts Redis-style configuration files, and works with existing Redis clients.

Valkey has continued to develop since the fork. Valkey 8 introduced multi-threaded I/O handling, and Valkey 9.0, released in October 2025, added atomic slot migration, hash field expiration, and support for multiple databases in cluster mode¹². Atomic slot migration is intended to make resharding less disruptive by moving slots atomically rather than exposing clients to the intermediate state of a slot migration, which classic resharding does through MOVED/ASK redirects that clients must handle.

Two limitations matter:

1. Valkey has added multi-threaded I/O, but its core command execution model remains primarily single-threaded, so it does not provide Dragonfly-style multi-core command execution.

2. Valkey does not ship the Redis 8 integrated feature set as part of its core distribution. Valkey maintains module API compatibility with the REDISMODULE_ interface, so some Redis modules run through it, while other Redis 8 capabilities require separate modules, alternative implementations, or architectural replacements. Compatibility needs to be evaluated module by module¹³.

Best for: Teams whose primary constraint is licensing and who use core Redis data structures rather than the Redis 8 integrated feature set.

Managed services: AWS ElastiCache, Microsoft Azure, and Google Cloud Memorystore

Managed services handle the work but don't address the underlying licensing question. AWS ElastiCache added Valkey support on October 8, 2024, pricing serverless Valkey 33% lower and node-based Valkey 20% lower than other supported engines at launch, with 99.99% availability, automatic failover, and in-place upgrade from Redis OSS¹⁴. Microsoft Azure and Google Cloud Memorystore offer comparable managed options across Redis and Valkey engines.

The tradeoff is operational lock-in. A managed service ties your high availability, backup, and multi-region replication behavior to one provider's implementation.

Best for: Teams that want managed operations and are already committed to a specific cloud.

Other architectural replacements

Several systems appear in Redis alternative comparisons. 

• Amazon DynamoDB is a serverless key-value service with a durability-first design and higher baseline latency than an in-memory store.

• Apache Ignite is a distributed computing platform with SQL support.

• Hazelcast is an in-memory data grid with distributed processing features.

• MongoDB has an in-memory storage engine and suits teams already running MongoDB.

Where compatibility becomes an issue

A RESP-compatible server accepts the same client connections as Redis. Your data, scripts, modules, transactions, persistence files, monitoring, and operational procedures are a separate question.

That matters more than throughput numbers. The Redis-compatible alternatives have RESP-compatible interfaces, but RESP compatibility covers the wire protocol, not complete command, scripting, transaction, persistence, or operational compatibility.

Aerospike is not in this table because it uses its own protocol and client libraries, so almost every row would read "not applicable." Its native types include lists and maps with server-side operations.

Application compatibility depends on which commands, modules, scripting, transaction semantics, and client-side assumptions your code uses. The table describes the protocol and data layers, not whether your specific application will run unchanged.

Two rows carry most of the migration risk: the data file boundary and version reporting.

The data file boundary. Valkey's migration documentation states that Redis OSS 2.x through 7.2.x use compatible protocol, configuration, and RDB/AOF formats, making migration effectively an upgrade, while Redis Community Edition 7.4 and later produce data files that are not compatible with Valkey. It is a significant constraint¹³.

Version reporting. Valkey reports redis_version:7.2.4 in its INFO output for backward compatibility, and exposes server_name and valkey_version to identify itself accurately¹³. That keeps old clients working but breaks dependency checkers that match on the name or version string.

Scripting and transaction semantics need individual testing.

• Aerospike does not use Redis scripting or MULTI/EXEC. Its multi-record transactions, added in Database 8, are opt-in and strictly serializable, so transaction logic is rewritten against Aerospike's client libraries rather than ported.

• Dragonfly coordinates multi-key operations across shards, so scripts and transactions that span several keys need to be tested against its sharded execution model.

• Garnet supports client-side RESP transactions and server-side stored procedures in C#, which is a different model from Redis MULTI/EXEC rather than a subset of it; an application relying on multi-key atomicity may not encounter this difference until production.

• KeyDB inherits Redis 6.2 behavior.

• Valkey inherits Redis 7.2 behavior.

Analyzing Dragonfly's 25x benchmark claim

Dragonfly is not 25x faster than the Redis you would actually run. The 25x figure compares Dragonfly with one Redis process on a 64-vCPU machine, a setup that leaves most of the 64 cores idle, and against a Redis Cluster with one shard per core, the gap mostly disappears, and Dragonfly may even be slower. The number is reproducible under those conditions, but it won't predict your results.

The benchmark documented in Dragonfly's repository ran on a c6gn.16xlarge instance with 64 vCPUs, using memtier_benchmark from a separate machine with thread counts tuned per instance type. Dragonfly crossed 3.8 million QPS, reaching 10 million QPS for SET and 15 million for GET in pipeline mode at depth 30.

Three factors explain why:

The Redis baseline. Redis uses more cores by running more processes, usually as Redis Cluster shards, rather than by multithreading one process. In a 2022 test on the same c6gn.16xlarge instance type, Redis reported that a 40-shard Redis 7.0 Cluster delivered 18% to 40% more throughput than Dragonfly while using 40 of the 64 vCPUs. That is a competitor's benchmark on older versions of both products, but it shows how much of the 25x gap comes from the baseline.

Core count. Redis' core command execution remains primarily serialized on a main thread, while I/O can be handled concurrently. Dragonfly distributes command execution itself across available cores. Against one Redis process on a 64-core machine, that difference is most of the result; against a cluster with a shard per core, the gap mostly disappears, and Dragonfly may even be slower. On a four-core instance, Dragonfly can use at most four cores to Redis' one, so its advantage tops out near 4x, not 25x.

Redis version and configuration. As published at the time of writing, Redis 8 introduced more than 30 performance improvements, including up to 87% lower command latency across a 149-test benchmark compared to Redis 7.2.5, and a new I/O threading implementation that Redis measured at up to 112% throughput improvement with io-threads set to 8 on a multi-core Intel CPU. Redis has continued improving 8.x performance.

When you see a Dragonfly-versus-Redis number, check what Redis it ran against: the version, whether it was a single process or a cluster, the instance type, and the persistence settings. A single unclustered process is not a tuned Redis 8 cluster.

Dragonfly's advantage is operational rather than raw throughput. It uses all of a large node's cores in one process, so you don't run and reshard a Redis Cluster or work within cluster mode's limits on multi-key operations. That matters most when clustering isn't an option for your application. Benchmark it on your instance sizes against the Redis version and topology you would otherwise run.

Calculating switching costs

The engine's price is not necessarily the largest migration cost. Three costs can easily exceed it.

1. Feature replacement is easy to underestimate. Redis 8 folded the formerly separate Redis Stack capabilities into the core distribution under the same tri-license as Redis itself, including Redis Search, JSON, Time Series, probabilistic data structures including Bloom and Cuckoo filters, the Redis Query Engine, and vector sets³. Valkey does not ship this set in core. A team relying on it faces a choice between community modules evaluated individually, a different system such as PostgreSQL with JSONB and pgvector, or a dedicated search engine. That choice affects the migration timeline more than the engine's list price does.

2. Minimum billing units matter more than discounts at small scale. At launch, AWS set a substantially lower minimum capacity for ElastiCache Serverless Valkey than for Redis OSS, a 100 MB floor versus 1 GB¹⁴. Absolute pricing has changed since launch and will keep changing, so check AWS's current ElastiCache pricing. Regardless, for a dozen mostly-idle staging environments, minimum capacity matters more than the percentage discount on the rate.

3. Legal review often settles the question before any benchmark does. Organizations maintaining an approved-license list frequently exclude copyleft licenses outright, regardless of the technical fit; that limits you to BSD-licensed Valkey or MIT-licensed Garnet regardless of merit.

Why swapping the cache engine may not be enough

Every Redis-compatible engine keeps the same architecture: a cache in front of a separate database. That stack has two response times, and whether a request is served by the cache or by the database behind it decides which one a user gets.

Cache misses aren't a fixed slice at the slow end of the latency distribution. They are whichever requests get sent to the database, and fan-out makes them matter. If each lookup independently has a 95% chance of hitting the cache, an interaction that needs 14 lookups has about a 49% chance that every one hits (0.95¹⁴), so more often than not it waits on the database at least once. Real access patterns are correlated, so the exact figure varies, but the direction holds.

Agentic AI workloads affect both aspects. An agent handling one user request can make far more than 14 data calls, and those calls are largely uncacheable because the agent composes them as it goes. The hit rate falls at the same time the fan-out grows.

Keeping two systems aligned is also ongoing work: warming the cache after deploys and restarts, invalidating entries when the database changes, and protecting the backend from cache stampedes. That work stays with the engineering team regardless of which Redis-compatible engine replaces Redis. An architecture that serves the full dataset directly, as Aerospike is designed to, removes the second system rather than swapping the first.

If your Redis deployment is a cache in front of a database and it fits comfortably in memory, the rewrite Aerospike requires is difficult to justify. The licensing and multi-core tradeoffs are the more applicable ones. If your dataset is outgrowing what RAM costs you and correctness under partition affects the decisions your application makes, Aerospike is an architecture worth evaluating for that comparison, rather than another Redis family system.

Migration timelines: The easy way and the hard way

For a simple ephemeral cache using only common Redis commands, a single-node migration can be mostly configuration work. A clustered production deployment is a different project. Even single-node migrations can involve persistence formats, ACLs, TLS configuration, eviction policy, metrics, monitoring, backup and restore, Lua scripts, and client library version checks.

The published guidance for the straightforward case is accurate. If you are running Redis OSS 7.2 or earlier, the protocol, configuration format, and RDB and AOF files are compatible, and Valkey documents this as effectively an upgrade¹³.

The hard case looks different. One Valkey community discussion describes a production migration involving a 15-node TLS cluster with roughly 159 million keys per cluster, replicated across approximately 100 data centers, running Redis 7.4¹⁵.

Three assumptions failed in sequence:

1. Rolling upgrade produced Valkey replicas reporting a downed master link and zero keys

2. RDB restore failed on format version 12

3. Offline replay tools required a per-cluster maintenance window that did not scale

The path discussed was a logical, type-aware copy that reads keys and writes normal commands into Valkey. This is one team's reported experience rather than a representative benchmark of Valkey migrations, but the problems that occurred are structural rather than incidental.

Four factors account for most migration overruns:

1. Source version above the fork point. Redis CE 7.4 and later data files are not compatible with Valkey, which invalidates snapshot-copy and full-sync approaches.

2. Sustained load behavior that short tests miss. Network and throughput limits on managed nodes can show up only after a load test has ended, so a passing test does not mean the cutover will work.

3. Module and feature dependencies discovered late. One RedisJSON call in one service can stall an otherwise complete migration.

4. Tooling that asserts on server identity. Health checks and dependency scanners matching on redis_version need updating before cutover.

Budget by source version and cluster topology rather than by data volume. A 100 GB Redis 7.2 cluster in one region is a simpler migration than a 20 GB Redis CE 7.4 cluster spanning regions.

When staying on Redis makes sense

You don't always need to migrate. Don't switch engines to solve a problem you don't have. A small, inexpensive cache that isn't causing problems, or a workload built mainly on Streams or Pub/Sub, rarely justifies the move.

If you use the Redis 8 integrated feature set heavily, Redis 8 is the only option covered in this guide that ships Search, JSON, Time Series, probabilistic data structures, the Query Engine, and vector sets together as part of the Redis Open Source distribution. Replacing that piecemeal is substantial work.

If you run Redis Cloud or Redis Software with an enterprise support agreement, you are buying an SLA, managed high availability, and access to a Redis expert. Community-supported alternatives do not replace that, and enterprise-grade Redis support has its own value.

If AGPLv3 is acceptable to your legal team and you do not offer a managed in-memory service, the restrictions of the tri-license may not affect you. The Redis ecosystem of client libraries, documentation, operational tooling, Redis Data Integration, and years of accumulated answers to obscure production questions remains the largest in this category.

Why a Redis alternative may not resolve a licensing concern

Every Redis-compatible engine covered here is either a fork of Redis or a reimplementation of the Redis protocol, which means the governance question from the licensing section above applies to each of them, not only to Redis itself. If licensing stability is your reason for evaluating alternatives, that is worth checking rather than assuming any move off Redis resolves it.

• Valkey addresses it through Linux Foundation governance and multi-vendor participation, which distributes control over the project's direction.

• Dragonfly is governed by one vendor under BSL terms with a scheduled Apache 2.0 conversion.

• KeyDB carries a stable BSD license, though ongoing maintenance is a concern.

These are different levels of risk, but none of them removes the governance question; it's simply answered differently in each case.

Aerospike is outside that lineage. It is not a Redis fork and does not implement the Redis protocol, so the Redis governance question doesn't carry over to it. Its terms are set by one vendor, Aerospike Inc.: the Community Edition server is licensed under AGPLv3, and the Enterprise Edition is commercially licensed. A policy that excludes AGPLv3 rules out Community Edition for the same reason it rules out Redis 8's open source option. For teams that already buy commercial database software, Enterprise Edition is a contract to evaluate like any other, and the case for Aerospike rests on its architecture rather than its license.

Where to go from here

The decision has four inputs:

1. The constraint you currently have

2. The durability and availability you need, including what a failover costs you

3. The license policy you must satisfy

4. The compatibility boundary imposed by your source version and topology

They are not strictly sequential. A durability requirement or a license policy can eliminate a candidate before you test anything; a source version can eliminate a migration path, and a workload requirement can eliminate an architecture.

• If the constraint is licensing, Valkey is the shortest path.

• If one Redis process is CPU-bound and Redis Cluster isn't an option, benchmark Dragonfly on your instance sizes against the Redis version and topology you would otherwise run.

• If the constraint is that your data has outgrown the memory you can afford while your latency target has not moved, or you are maintaining a cache and a database for the same data, the comparison is architectural, and Aerospike's architecture is worth evaluating.

• If the constraint is what happens when a node fails, test each candidate under failure before comparing throughput: whether acknowledged writes survive, whether reads go stale, and how long requests stall while the cluster recovers.

Start by establishing three facts: what a failover is allowed to cost you, your Redis source version, and your organization's position on AGPLv3. Any one of them can rule out entire migration options.