Redis Alternatives: Valkey, Dragonfly, KeyDB, Garnet, and Memcached

The best Redis alternative depends on what "Redis" means inside your application. For a permissively licensed, close continuation of Redis 7.2, start with Valkey. For higher throughput on a large multi-core server, test Dragonfly. For a .NET-friendly cache with an MIT licence, look at Garnet. Choose KeyDB for its active-active replication model, and choose Memcached only when the workload is a disposable cache of opaque values.

Redis itself remains a strong option. Redis 8 restored an OSI-approved licence choice through AGPLv3 and folded Search, JSON, Time Series, and Bloom features into the main distribution. Switching now needs a technical reason, not a recycled headline from 2024.

Alternative	Protocol compatibility	Licence	Best fit	Main caution
Valkey	Closest to Redis 7.2	BSD 3-Clause	General Redis replacement	New Redis 8 commands and bundled modules differ
Dragonfly	Redis and Memcached APIs	BSL 1.1	High throughput on multi-core servers	Not every command or operational behaviour matches Redis
KeyDB	Redis protocol, modules, and scripts	BSD 3-Clause	Active-active replication and multithreading	Slower public development cadence
Garnet	RESP, with many Redis commands	MIT	.NET shops and high-connection caches	Smaller command and module ecosystem
Memcached	Its own text and binary protocols	BSD 3-Clause	Plain distributed caching	No Redis data structures, persistence, or server-side replication

Why teams look for Redis alternatives

The 2024 licence change triggered much of the current search demand. Redis 7.4 moved away from BSD to RSALv2 and SSPLv1, neither of which is an OSI-approved open-source licence. Cloud providers and teams with strict licence policies started evaluating forks.

The position changed again with Redis 8. Redis now offers a choice of RSALv2, SSPLv1, or AGPLv3, and AGPLv3 is OSI approved. Redis 7.2 and earlier remain BSD licensed. Redis 8 also includes capabilities that previously shipped as separate Redis Stack modules.

Licensing still matters. AGPL is a strong copyleft licence, Valkey and KeyDB use permissive BSD terms, Garnet uses MIT, and Dragonfly's BSL restricts offering the software as a competing managed service. Legal requirements differ, so read the licences rather than treating "open source" as one category.

Other teams are looking for a different architecture. Redis has added I/O threads and continues to improve multi-core use, but much of its command execution model remains centred on one main thread. Dragonfly, KeyDB, and Garnet were designed to spread work across cores. That can matter when one instance is CPU-bound and the alternative to scaling up is operating a cluster.

Valkey: the safest general replacement

Valkey forked from Redis 7.2 before the 2024 licence transition. It is a Linux Foundation project under the BSD 3-Clause licence and retains Redis's core data structures, persistence models, replication, Sentinel, clustering, Lua scripting, transactions, and familiar command-line workflow.

Valkey is the first alternative to test when an application already uses Redis clients and ordinary commands. Existing redis-py, node-redis, Jedis, go-redis, and other RESP clients can connect because the wire protocol and command model share the same origin.

The important word is "test." Redis and Valkey are separate projects now. Redis 8 includes newer commands and the former Redis Stack modules in its main distribution, while Valkey has its own modules and release path. A service that uses strings, hashes, sets, sorted sets, streams, Pub/Sub, Lua, transactions, and common expiry commands has a much easier migration than one built around Redis Search or another module.

Choose Valkey when:

• A permissive licence is a hard requirement.
• You want the smallest change from a Redis 7.2 deployment.
• Sentinel or Redis-style clustering is already part of your operations model.
• Broad client compatibility matters more than changing the server architecture.

Check before migrating: modules, ACL rules, Lua scripts, command flags, persistence files, cluster tooling, and managed-service support.

Dragonfly: scale up before you scale out

Dragonfly implements Redis and Memcached APIs on a multi-threaded, shared-nothing architecture. It partitions the keyspace between threads so one process can use a large machine more effectively than a single-threaded design.

That architecture is the reason to consider Dragonfly. If a Redis workload is limited by one hot CPU while memory and other cores sit underused, a vertically scalable server can reduce the need for sharding. Dragonfly supports snapshots, replication, expiry, eviction, common Redis data structures, and a large command set.

Protocol compatibility is not behavioural identity. Dragonfly documents command and configuration differences, and its cluster support does not reproduce every part of Redis Cluster. Workloads that rely on modules, obscure commands, exact eviction behaviour, or operational scripts need a command-by-command review.

Dragonfly uses the Business Source License 1.1. Its additional use grant permits production use as part of your own product or service, but restricts offering Dragonfly itself as a managed or competing service. The source converts to Apache 2.0 on the licence's stated change date.

Choose Dragonfly when:

• One Redis instance is CPU-bound on a multi-core machine.
• Consolidating shards would reduce operational work.
• Your command surface fits Dragonfly's compatibility list.
• BSL terms fit how you deploy and distribute your product.

Do not adopt a vendor's headline benchmark as a capacity plan. Replay your key sizes, command mix, pipeline depth, connection count, expiry pattern, and persistence settings on the hardware you intend to run.

KeyDB: active-active writes and familiar internals

KeyDB is a multi-threaded Redis fork maintained by Snap. It keeps Redis protocol, script, transaction, and module compatibility while adding features such as active replication, where multiple instances can accept writes and replicate to each other.

Active-active operation is the main reason to choose KeyDB. It can make failover and geographically distributed writes easier for workloads whose conflict behaviour fits KeyDB's replication model. KeyDB also uses multiple server threads and offers MVCC-based non-blocking scans.

The trade-off is project momentum. The public repository remains available and is not archived, but its main branch has seen a slower development cadence than Valkey, Redis, or Dragonfly. That does not make deployed software stop working. It does mean a new adopter should inspect recent releases, security response, client compatibility, and the issue tracker before making it a long-lived dependency.

Choose KeyDB when: active-active replication solves a specific problem and you have validated the project's support profile. For a general BSD-licensed Redis replacement, Valkey is the safer starting point.

Garnet: a modern RESP server from Microsoft

Garnet is an MIT-licensed cache-store from Microsoft Research. It speaks RESP, so unmodified Redis clients can connect for supported commands. Its storage engine supports memory and SSD tiers, checkpointing, recovery, an operation log, transactions, and a cluster mode with sharding and replication.

Garnet is written in C# and is especially interesting for teams already comfortable with .NET operations and extension development. Server-side procedures and custom commands can be written in C#, which is a different extension path from Redis modules and Lua scripts.

Compatibility is narrower than shared ancestry. Garnet started from the Redis protocol, not the Redis codebase, and implements commands on its own storage engine. Its cluster control plane also differs: the server handles sharding, replication, and key migration, but leader election is left to an external control plane.

Choose Garnet when: MIT licensing, .NET integration, high connection counts, or tiered storage matter, and your application uses a command set Garnet supports.

Memcached: use less when less is enough

Memcached is not a Redis clone. It is a distributed in-memory cache for keys and opaque values. Servers do not coordinate or replicate with each other; the client chooses a server, and eviction is an expected part of the design.

That limited model is useful. If the application only caches serialized database results with a time-to-live, Redis hashes, sets, streams, scripting, persistence, and replication may be unnecessary. Memcached is easy to reason about because losing cached values is part of normal operation.

It is the wrong alternative when Redis is a queue, session system that cannot lose data, rate limiter with scripts, leaderboard, stream processor, or primary store. Our Redis vs Memcached comparison goes deeper on that boundary.

Redis alternatives that are not drop-in replacements

Some searches for Redis alternatives are questions about architecture rather than protocol compatibility.

PostgreSQL can replace Redis for durable queues, rate limits, sessions, JSON documents, and advisory locks when the application already depends on Postgres. This removes a service at the cost of higher latency and less specialised data structures. FOR UPDATE SKIP LOCKED is enough for many work queues; our PostgreSQL job queue guide shows the pattern.

Kafka, RabbitMQ, and NATS are better fits when Redis is being stretched into a durable message broker. They bring delivery semantics, consumer coordination, and operational models designed around messages rather than cached data.

DynamoDB and other managed key-value stores fit durable, horizontally scaled key access when sub-millisecond in-memory latency is not required. They change the API and cost model, but remove cache-server operations.

The best migration can be deleting Redis from a path that did not need it. Replacing one in-memory server with another preserves the architecture, including any mistake in that architecture.

Compare the command surface, not the logo

Before choosing an alternative, capture the commands the application sends in production. Group them into these areas:

1. Core types: strings, hashes, lists, sets, sorted sets, streams, and geospatial indexes.
2. Atomic behaviour: transactions, Lua scripts, functions, and multi-key operations.
3. Expiry and eviction: TTL precision, policies, memory limits, and keyspace notifications.
4. Durability: snapshots, append-only logs, recovery time, and acceptable data loss.
5. Topology: replication, failover, Sentinel, cluster redirects, resharding, and cross-zone traffic.
6. Security: ACL categories, TLS, certificates, authentication, and audit requirements.
7. Extensions: Search, JSON, Bloom filters, time series, or custom modules.
8. Operations: metrics, backups, upgrade procedure, client tracking, and managed-service availability.

A server can accept PING, GET, and SET from a Redis client and still fail the application on a Lua script, a blocking stream read, or a cluster redirect. "Redis compatible" describes a range, not a certification.

A practical migration test

Run the candidate beside Redis before changing production traffic.

Start with a fresh instance using the same memory ceiling and persistence expectations. Replay a representative command trace or load test, then compare throughput and p95/p99 latency rather than average latency alone. Include a snapshot or checkpoint during the test because persistence often changes the result.

Next, test failure. Kill the primary during writes, restart from disk, promote a replica, and confirm how much acknowledged data survived. Check client reconnection and retry behaviour. A faster steady-state benchmark does not compensate for a recovery process the team cannot operate.

Finally, run application integration tests with command logging enabled. Look for unknown commands, changed return values, transaction conflicts, script errors, and cluster behaviour. DB Pro's Redis desktop client can inspect keys and run commands against a test instance, but production compatibility still belongs in automated tests.

Which Redis alternative should you choose?

Choose Valkey for the closest permissively licensed replacement and the strongest default recommendation.

Choose Dragonfly when vertical scaling is the goal and benchmarks with your own workload show a meaningful advantage.

Choose KeyDB when active-active replication is the deciding feature and its support cadence meets your requirements.

Choose Garnet when its RESP coverage, MIT licence, .NET extension model, and storage architecture fit the application.

Choose Memcached when every value is disposable cache data and the application needs none of Redis's richer behaviour.

Stay with Redis when Redis 8 features, modules, managed services, documentation, and operational familiarity are worth more than changing licence or architecture. If the current system is slow, measure it before migrating. The fixes in our Redis performance guide are cheaper than replacing a server that was waiting on a few bad commands.