Redis Alternatives: Open Source Options and Replacements Compared

The main Redis alternatives are Valkey, Dragonfly, Garnet, KeyDB and Memcached, plus the managed Valkey services on AWS and Google Cloud. Valkey is the closest replacement: a BSD-licensed Linux Foundation fork of Redis 7.2.4 that existing clients and data files move to unchanged. Dragonfly and Garnet are newer engines that speak the Redis protocol, Memcached replaces Redis only as a plain cache, and staying on BSD-licensed Redis 7.2 is a legitimate choice too. Every license and compatibility claim below was checked against the project's own site or repository on 9 October 2026.

Why teams look for a Redis alternative

• The license. On 20 March 2024 Redis Ltd. announced that from Redis 7.4 the server would move from BSD-3-Clause to a choice of RSALv2 or SSPLv1, neither of which is an OSI-approved open source license. Redis 8 added AGPLv3 as a third option. AGPLv3 is open source, but its network-use terms still send it to legal review in many companies.
• Commercial cost. Redis Enterprise and Redis Cloud are paid subscriptions. Teams that bought them for one feature often find an open-source engine now covers what they use.
• End of life. Redis 7.0 is already out of support and Redis 6.2 reaches end of life on 1 April 2027. An upgrade that has to happen anyway is a natural moment to reconsider the engine; the dates by version are in Redis end of life.
• Threading. Redis executes commands on one main thread; Dragonfly, Garnet and KeyDB use every core, which matters for a few very hot instances.

The table records what each project documents, not how it behaves at your scale. Vendor benchmarks are left out.

Valkey continues Redis 7.2.4 under BSD-3-Clause and is run by the Linux Foundation. Its current line is Valkey 9.1. For anyone on Redis 7.2 or earlier, moving to Valkey is effectively an upgrade: same protocol, same configuration, same data files. From Redis 7.4 or later the data files do not load, so a move means replicating or exporting keys.

License history, divergence since the fork and migration detail are in Valkey vs Redis. AceMQ provides 24/7 Valkey support for the move and after it.

Dragonfly is a multithreaded in-memory store that implements the Redis and Memcached APIs and states that adopting it needs no code changes. It is licensed under the Business Source License 1.1, which is source-available rather than open source. The additional use grant allows production use only as part of your own product or service that is not itself an in-memory data store, and not offered to third parties as a service. Each version converts to Apache 2.0 at the change date in the license file, currently 1 November 2030, or four years after that version's first public release, whichever comes first. For an internal cache that is usually acceptable. For a platform or hosting business it is the same question that pushed people away from RSALv2.

Dragonfly persists with point-in-time snapshots taken without forking the process, and can run an emulated cluster on a single node so Redis Cluster clients connect unchanged. Multi-node clustering exists, but Dragonfly documents that the server provides only a data plane: health checks, failover and slot migration need an external control plane, which Dragonfly offers in its own cloud service.

Garnet is a cache-store from Microsoft Research, written in C# on .NET, released under the MIT license and running on Linux and Windows. It speaks RESP, so unmodified Redis clients connect to it. Cluster mode supports sharding, replication and key migration, but the cluster is passive: it acts on cluster commands from a control plane you supply instead of electing leaders itself. Persistence is through checkpoints and an append-only log.

Three differences to test. Redis modules do not load, because Garnet has its own C# extension model. Lua scripting is off until enabled with a startup switch. And MSET is not atomic, because of the multithreaded design.

KeyDB, maintained by Snap Inc., is a BSD-3-Clause fork of Redis that adds multithreading, active replication and multi-master setups on top of Redis persistence and clustering. Its command set sits at the Redis 6 level, so Redis 7 additions such as Functions are absent. The last tagged release, 6.3.4, was published on 30 October 2023, and the repository was last updated on 29 May 2024.

That does not make KeyDB broken, but it makes it a fork you would maintain yourself, without upstream security fixes.

Memcached is BSD-licensed, mature and very fast at one job: a volatile key-value cache. It does not speak the Redis protocol, stores values without Redis data structures, has no replication and no durable persistence. Its warm restart feature, from version 1.5.18, can recover the cache after a clean restart, and the documentation states plainly that this does not make it crash safe.

If the application uses Redis for sessions that must survive a restart, queues, sorted sets or pub/sub, Memcached is not a replacement. The trade-offs are covered in Redis vs Memcached.

If the cache already lives in a cloud, the provider may already offer the switch. AWS launched Amazon ElastiCache for Valkey and Amazon MemoryDB for Valkey on 8 October 2024, and says an ElastiCache for Redis OSS cache can be upgraded to Valkey in a few clicks with zero downtime. Google Cloud's Memorystore for Valkey supports Valkey 7.2, 8.0, 9.0 and 9.1, with cluster mode enabled or disabled and RDB or AOF persistence.

Azure is the exception. Azure Managed Redis runs Redis Enterprise software, and Azure Cache for Redis is being retired, so on Azure the managed path is Redis rather than an alternative to it. Teams that want Valkey there run it themselves. The services are compared side by side in managed Redis options.

Not every team needs a new engine. Redis 7.2 is the last BSD-3-Clause release, and Redis lists it as an extended release supported until 1 December 2029. Teams on 6.2 or 7.0 can move to 7.2 without touching the license question at all.

Where even that upgrade is blocked, OSSeva, AceMQ's extended support platform, backports CVE fixes to Redis 6.2.x, 7.0.x and 7.2.x, and to Valkey 7.2.x and 8.x. Patches arrive as GPG-signed Docker images and apt or yum packages, and the Redis builds keep the BSD license you already run. Paired with 24/7 Redis support, the engine decision can be made on features rather than under a security deadline.

1. Is Redis only a volatile cache? Memcached is an option. Anything with persistence, data structures or pub/sub needs a Redis-protocol engine.
2. Is the concern the license? Valkey or Redis 7.2, both BSD-3-Clause. Dragonfly's BSL and Redis 8's AGPLv3 both need a legal read first.
3. Is the cache managed on AWS or Google Cloud? Switch the engine to Valkey inside the same service.
4. Do you depend on Redis 8 features such as built-in JSON, time series, vector sets or the Query Engine? No alternative reproduces them exactly; test Valkey's modules or stay on Redis.
5. Is a single instance CPU-bound? Benchmark Dragonfly and Garnet against Valkey 8 or later with I/O threads enabled, on your own workload, before changing engines.

Whichever option wins, test it against the commands, modules and persistence settings you actually use; a Redis health check produces that list.

• Redis — Licenses (RSALv2, SSPLv1, AGPLv3 by version)
• Redis — Redis Open Source version management
• Valkey — project home
• Dragonfly — LICENSE.md (Business Source License 1.1)
• Dragonfly — Cluster mode documentation
• Microsoft Garnet — GitHub repository
• Microsoft Garnet — API compatibility
• KeyDB — GitHub repository and releases
• Memcached — Warm restart
• AWS — Amazon ElastiCache for Valkey (8 October 2024)
• AWS — Announcing Amazon MemoryDB for Valkey
• Google Cloud — Memorystore for Valkey overview
• Microsoft Learn — What is Azure Managed Redis?
• OSSeva — Redis and Valkey extended support