Open Source Tools

3 Best Open Source Alternatives to Redis

Updated July 2026

Most reasons to leave a database are technical. This one is a license. Redis spent years as permissively licensed open source and became default infrastructure for caching, queues, rate limits, and pub/sub because of it. In 2024 its core moved to a source-available license, and the parts of the community that had built on it as genuinely open software did not follow - major contributors and sponsors forked the last open release and kept developing it under an open license instead. The alternatives below speak the same protocol and commands, so existing clients and tooling keep working, while the governance and code stay open in a way that cannot be pulled out from under you later.

Dragonfly logo

1.Dragonfly

30.7kOtherC++ Self-host
Dragonfly screenshot

Dragonfly is an in-memory data store for modern application workloads. It is compatible with Redis and Memcached APIs, so applications can adopt it without code changes. It targets cache and key-value database use cases while preserving atomicity guarantees for operations and low, sub-millisecond latency over high throughput.

  • Compatible with Redis and Memcached APIs
  • Supports about 185 Redis commands and all Memcached commands except cas
  • Shared-nothing architecture partitions the keyspace between threads
  • Cache mode with adaptive eviction near the maxmemory limit
More about DragonflyVisit website
Valkey logo

2.Valkey

26.1kOtherC Self-host
Valkey screenshot

Valkey is a high-performance data structure server for key/value workloads, optimized for caching and other realtime workloads. It was forked from the open source Redis project right before Redis moved to new source available licenses, giving teams an open source path for Redis-style workloads.

  • Key/value workloads with native data structures
  • Plugin system for new data structures and access patterns
  • Server configuration by valkey.conf or command line options
  • Optional TLS support, built in or as a module
More about ValkeyVisit website
KeyDB logo

3.KeyDB

12.5kBSD-3-ClauseC++ Self-host
KeyDB screenshot

KeyDB is a high performance fork of Redis focused on multithreading, memory efficiency, and high throughput. It keeps full compatibility with the Redis protocol, modules, and scripts, including atomicity guarantees for scripts and transactions, so existing Redis deployments can use it as a drop-in replacement.

  • Multithreaded Redis-compatible server
  • Full Redis protocol, module, and script compatibility
  • Active Replication for hot-spare failover
  • MVCC architecture for non-blocking KEYS and SCAN
More about KeyDBVisit website

Our picks

All three keep Redis clients working; they differ in lineage and priorities.

The community fork under the Linux Foundation: Valkey Valkey was forked from the open source Redis project just before Redis adopted its source-available licenses, and it is now an open community project under the Linux Foundation. It keeps Redis's native data structures and a familiar valkey.conf, adds a plugin system for new data types, and builds across Linux, macOS, and the BSDs. For teams whose only real complaint with Redis is the license change, it is the most direct continuation.

For module and script compatibility with more throughput: KeyDB KeyDB is a Redis fork under a BSD-3 license that keeps full compatibility with the Redis protocol, modules, and scripts, so many deployments can treat it as a drop-in. Its focus is throughput and availability: multithreading, an MVCC design that lets KEYS and SCAN run without blocking, and active replication for hot-spare failover. Maintained by Snap as part of its own caching infrastructure.

For raw per-node performance: Dragonfly Dragonfly is a from-scratch in-memory store compatible with the Redis and Memcached APIs, implementing roughly 185 Redis commands. Its shared-nothing architecture partitions the keyspace across threads for high throughput, and a cache mode adds adaptive eviction near the memory limit. A native HTTP console and Prometheus-compatible metrics make it easy to operate. Reach for it when per-node performance matters more than exact feature parity.

Choosing a Redis-compatible server without surprises

Compatibility is a spectrum, not a yes or no. A server that handles GET, SET, and simple hashes may still diverge on the parts that carry real load: stream consumer groups, blocking commands, Lua script determinism, keyspace notifications, exact eviction under memory pressure, and Redis Cluster routing. Build a command inventory from production metrics before you trust any compatibility claim, then weigh how many of Redis's roles - cache, queue, lock, leaderboard, message bus - you are asking one replacement to cover.

The closest lineage is Valkey, forked from the last open source Redis release and now developed under the Linux Foundation, so it tracks the same data structures and configuration file with an open license behind it. KeyDB is an older Redis fork under a BSD license that keeps full protocol, module, and script compatibility while adding multithreading and active replication, which suits teams who leaned on Redis modules or wanted more throughput per node. Dragonfly takes a different route: a multithreaded, shared-nothing rewrite that reimplements around 185 Redis commands plus the Memcached API, aimed at raw throughput rather than exact feature parity.

Migration off Redis starts with measurement, not export. Capture command usage, key counts, value sizes, TTL distribution, and persistence settings first. For protocol-compatible targets you can often load from snapshots or append-only logs, or use DUMP and RESTORE where formats match; for a safer cutover, dual-write for a window, compare reads, then move clients by endpoint. Validate TTLs, stream offsets, scripts, and ACLs explicitly, since these are where compatible servers most often behave differently.

Related alternatives

Firebase9Google Analytics9NotebookLM3Oracle Database5YugabyteDB5Splunk13

Frequently asked questions

Is Redis still open source?+

Redis releases from 2024 onward use source-available licenses that are not generally treated as open source. Older Redis code and the community forks carry different terms - Valkey continues under the Linux Foundation, and KeyDB uses a BSD-3 license. If licensing is your reason for switching, have legal or compliance review both the replacement's license and your deployment model, since the answer depends on the exact version and distribution you run.

Will my existing Redis client libraries keep working?+

Often yes, if the server speaks the Redis protocol and supports the commands your application sends. The risky parts are cluster routing, authentication, TLS, pub/sub, pipelining, transactions, and error messages that clients parse. KeyDB keeps full protocol compatibility, and Valkey continues Redis's command surface directly. Test with the same client versions you run in production, including reconnect behavior during failover and resharding.

What happens to my Lua scripts?+

Do not assume scripts are portable just because the target accepts the same command names. Redis script behavior depends on deterministic execution, command restrictions, key access rules, and replication semantics. KeyDB advertises full script compatibility, but still inventory every script by SHA and source, run them against realistic data, and check both return values and side effects. Complex scripts may be better moved into application code.

Do the forks support Redis modules?+

Module support is one of the least portable parts of a Redis deployment, and it varies by fork. KeyDB keeps full module compatibility, while a from-scratch server like Dragonfly reimplements a fixed command surface and does not run arbitrary Redis modules. If your application depends on module-provided types, search, time series, or JSON operations, verify support before planning a drop-in move, because module data may not export through normal Redis paths.

Which Redis data structures are most likely to cause trouble?+

Simple strings and hashes usually move cleanly. Streams, sorted sets with tight ordering assumptions, geospatial indexes, HyperLogLog values, bitmaps, and module-created values deserve extra testing. The question is not only whether the type exists, but whether edge cases match Redis under trimming, expiration, blocking reads, score ties, and concurrent writers. Build a command inventory from production and test against that, not a broad compatibility claim.

Can these servers handle Redis Cluster workloads?+

Some support Redis Cluster-style behavior while others expect a different sharding model. Check hash slot routing, MOVED and ASK responses, multi-key command rules, resharding, replica promotion, and client library support. A small cluster test is not enough - simulate node loss, slot migration, and client reconnect storms before moving production traffic. Dragonfly's shared-nothing threading and KeyDB's active replication scale differently, so test your own topology.

Will TTLs and eviction behave the same after switching?+

Not automatically. Redis TTLs, lazy and active expiration, and eviction policies interact with memory limits and workload shape, and a replacement may sample, account for memory, or clean up in the background differently. Dragonfly's cache mode uses an adaptive eviction algorithm near the memory limit, which is not identical to Redis. For cache workloads, test under the memory pressure you expect; for correctness-sensitive keys, avoid depending on exact expiration timing.