Choosing an in-memory data store used to be a one-word answer: Redis. That answer fractured in 2024 and 2025. This architecture decision record frames the Valkey vs Redis vs Dragonfly question the way a platform team actually faces it — as a decision with a license clause attached. We will treat each engine as a candidate, score them against real decision drivers, and write down the consequences you accept with each pick. The goal is not to crown a universal winner. It is to give you a defensible record you can paste into a design doc and revisit in a year.
This is written as an ADR on purpose. Caching choices outlive the engineer who made them. A clear context, a scored options table, and an honest consequences section beat a benchmark screenshot every time.
Context and problem statement
For more than a decade, Redis was the default. Teams reached for it reflexively for caching, session storage, rate limiting, queues, and leaderboards. The API was familiar, the ecosystem was deep, and the BSD license meant nobody read the LICENSE file twice.
That changed in March 2024. Redis Ltd. relicensed the core away from the permissive BSD-3 license to a dual model of the Redis Source Available License v2 (RSALv2) and the Server Side Public License v1 (SSPLv1). Neither is an OSI-approved open source license. Both restrict offering Redis as a managed service. The Linux Foundation responded within days by launching Valkey, a fork of Redis 7.2 that stays under BSD-3, backed by AWS, Google Cloud, Oracle, and others.
In 2025 Redis softened its stance. Starting with Redis 8, it added the GNU Affero General Public License v3 (AGPLv3) as an additional licensing option. AGPLv3 is OSI-approved, so Redis 8 can again be called open source — but AGPLv3 carries strong copyleft and network-use obligations that some organizations cannot accept. So the Redis fork 2026 landscape is no longer a fork versus an original. It is three viable, actively developed engines with three different license postures and three different scaling philosophies.
That is the decision this record addresses. When a team stands up a new cache or in-memory primary in 2026, the Redis-by-default reflex is no longer safe. The choice now touches legal, platform, and cost owners at once.
A short timeline of the split
It helps to fix the sequence in your head, because the licenses changed more than once.
- Before 2024. Redis ships under BSD-3, a permissive open source license. It is the uncontested default for in-memory storage.
- March 2024. Redis Ltd. relicenses the core to RSALv2 and SSPLv1. Both are source-available, neither is OSI-approved, and both restrict managed-service competitors.
- Days later. The Linux Foundation launches Valkey as a BSD-3 fork of Redis 7.2, with cloud-vendor backing and foundation governance.
- 2025. Redis 8 adds AGPLv3 as a third licensing option, restoring an OSI-approved open source path while keeping the source-available options.
- Throughout. Dragonfly continues as an independent, BSL-licensed engine built from scratch, unaffected by the fork drama because it was never Redis.
The practical takeaway is that “open source Redis” is now ambiguous. You have to name the version and the license you mean. That ambiguity alone is why the decision deserves a written record rather than a hallway answer.
Decision drivers
These are the factors a platform team weighs. We will score every option against them in the comparison matrix later. They are listed roughly in the order most teams rank them in 2026.
- Licensing and governance. Is the license OSI-approved and permissive? Who controls the roadmap — a single vendor or a neutral foundation? This is the driver that moved first and moves everything else.
- Throughput and scaling model. Does the engine scale up by using more cores on one box, or scale out across many small nodes? This shapes your cost curve and your operational shape.
- Clustering and high availability. How does the engine shard data and survive node loss? Native cluster mode, replication, and automatic failover all matter.
- Compatibility. How close is it to the Redis API and wire protocol you already depend on? A true drop-in replacement removes most migration risk.
- Memory efficiency. How many bytes does the engine spend per stored byte? At scale this is a direct line item on your cloud bill.
- Operational maturity. How battle-tested are the failure modes, tooling, observability, and managed offerings? New does not mean unproven, but it means fewer war stories.
- Ecosystem. Modules, client libraries, search, JSON, and the surrounding tooling. Some workloads live entirely inside extensions, not the core.
A short note on internal context. If your store is part of a larger data platform, read this alongside our distributed SQL ADR. The cache tier and the system of record have to fail in compatible ways.
Options considered
Three serious candidates. Each takes a different architectural bet. The diagram below contrasts their threading and scaling models at a glance — it is conceptual, not a benchmark.
Valkey
Valkey is the Linux Foundation’s BSD-3 fork of Redis 7.2. It is governed by a technical steering committee rather than a single company, and its early backers — AWS, Google Cloud, Oracle, Ericsson, and Snap — fund and ship code. That governance model is the headline feature for many adopters.
Architecturally, Valkey began as Redis and kept the design that made Redis predictable: a single-threaded command processing core, point-in-time RDB snapshots, append-only file (AOF) persistence, and Redis Cluster for horizontal sharding. The fork has not stood still. Valkey has invested in multi-threaded improvements to the I/O and command path, so more cores translate into more throughput on a single node than legacy Redis delivered. It also added features like dual-channel replication to speed up full syncs.
For a team whose main worry is the license and whose main constraint is “do not break our existing Redis integration,” Valkey is the lowest-surprise option. It speaks the same protocol, uses the same data types, and runs the same Lua scripts.
The governance point deserves a second look, because it is structural rather than cosmetic. A single-vendor project can relicense overnight, as 2024 proved. A Linux Foundation project cannot — its license and trademark sit with a neutral body, and no single backer can unilaterally pull it source-available. For organizations that were burned once and do not want to be burned again, that structural guarantee is worth as much as any feature. The major clouds now offer Valkey as a managed service, which means you can adopt it without committing to self-managed operations from day one.
Redis (8.x)
Redis 8 is the current line from Redis Ltd. The big change is licensing: alongside RSALv2 and SSPLv1, Redis 8 offers AGPLv3, restoring an OSI-approved open source path. Redis 8 also folded the formerly separate Redis Stack capabilities — search, JSON, time series, probabilistic structures — into the core distribution, so a single Redis 8 binary now ships those modules.
The core execution model remains a single-threaded command loop with I/O threads handling network work, and Redis Cluster handling horizontal scale. This is the most mature, most documented, most widely deployed design in the category. Two decades of production behavior are written down somewhere.
The catch is governance and license. Redis 8’s roadmap is set by a single vendor, and the AGPLv3 option — while genuinely open source — imposes network copyleft that many enterprises route around by policy. If you need the deepest module ecosystem and can accept that license posture, Redis 8 is the feature-richest choice.
It is worth being fair to Redis 8 here, because the bundling is a real upgrade. For years, teams that wanted vector search, JSON documents, or time-series data inside Redis had to install separate modules and manage their versions independently. Folding those into the core binary removes a class of operational friction. If your application leans on those data structures, Redis 8 gives you a single, supported artifact instead of an assembly job. That convenience is precisely what makes a move to Valkey or Dragonfly harder for module-heavy workloads — you would be trading a bundled feature set for a license you prefer.
Dragonfly
Dragonfly is the outlier. It is not a Redis fork; it is a from-scratch engine that is wire-compatible with both Redis and Memcached. Its design bets on vertical scaling. Dragonfly uses a shared-nothing, multi-threaded architecture: each thread owns a slice of the keyspace and runs largely without locks, so adding cores adds throughput without the coordination overhead of a shared heap.
The pitch is operational simplicity at scale. Instead of running a 20-node Redis cluster to use 20 cores, you run one large Dragonfly instance that uses all of them. Multi-threaded, shared-nothing designs scale up by design, which can collapse a cluster’s worth of nodes into a single process. The Dragonfly database is distributed under the Business Source License (BSL). BSL is a source-available license that converts to a permissive license after a set time. In the interim it restricts offering Dragonfly as a competing managed service.
Dragonfly is the youngest of the three. That buys it a clean modern design and costs it the decades of edge-case hardening that Redis accumulated.
The shared-nothing idea is worth understanding because it explains the whole trade-off. In a classic single-threaded Redis, one core does the command work and other cores sit mostly idle, so you scale by running more processes — often one per core, each a cluster member. Dragonfly instead partitions the keyspace across threads inside one process. A given key always lives on the same thread, so most operations never contend for a lock. The result is that one Dragonfly process can saturate a large machine. The cost is that all that capacity lives behind a single failure domain, so your HA story is about replication and fast failover rather than spreading risk across many small nodes.
Comparison matrix
Below is a weighted score across the decision drivers. Weights reflect a typical platform team in 2026 where licensing concern is high; adjust them to your own priorities. Scores are 1 to 5, where 5 is strongest. These reflect design posture and general consensus, not a benchmarked leaderboard.
| Driver | Weight | Valkey | Redis 8.x | Dragonfly |
|---|---|---|---|---|
| Licensing and governance | 25% | 5 (BSD-3, foundation) | 2 (AGPLv3/source-available, single vendor) | 3 (BSL, single vendor) |
| Throughput and scaling model | 20% | 4 (multi-thread, scale-out) | 3 (scale-out cluster) | 5 (shared-nothing, scale-up) |
| Clustering and HA | 15% | 5 (mature Redis Cluster) | 5 (mature Redis Cluster) | 3 (newer, fewer war stories) |
| Compatibility | 15% | 5 (drop-in, same lineage) | 5 (it is Redis) | 4 (wire-compatible, not 100%) |
| Memory efficiency | 10% | 4 | 4 | 4 |
| Operational maturity | 10% | 4 (Redis heritage) | 5 (most deployed) | 3 (youngest) |
| Ecosystem | 5% | 4 (broad client support) | 5 (bundled modules) | 3 (core types focus) |
| Weighted total | 100% | 4.55 | 3.55 | 3.70 |
Read this table as a starting frame, not a verdict. Change the licensing weight to 5% and Redis 8 jumps. Change the scaling weight to 40% because you run one enormous cache, and Dragonfly leads. The matrix exists to make your weights explicit. The decision tree below turns those weights into a path.
Consequences
Every choice closes some doors. Here is what you accept with each.
If you choose Valkey, you accept a younger brand name on your runbooks and a fork that — while feature-compatible with Redis 7.2 — may diverge from Redis’s newest proprietary features over time. In exchange you get a permissive BSD-3 license, neutral foundation governance, multi-threaded throughput gains, and a drop-in path from existing Redis. For most teams whose primary driver was the license shake-up, this is the default landing spot.
If you choose Redis 8.x, you accept single-vendor governance and an AGPLv3-or-source-available license posture that your legal team must sign off on. You also accept that managed-service restrictions apply if you ever wanted to resell it. In exchange you get the most mature engine, the deepest documentation, and bundled search, JSON, and time-series modules in one binary.
If you choose Dragonfly, you accept the youngest engine, the BSL license with its time-delayed conversion and competitive-use restriction, and wire compatibility that covers the common path but not every command or module. In exchange you get a vertical-scaling architecture that can replace a multi-node cluster with one big instance, simplifying topology and often cost.
The HA and clustering topologies differ in a way worth picturing. Redis and Valkey shard across many primaries with replicas; Dragonfly tends toward one large primary with a failover replica.
The clustered model gives you fine-grained horizontal scaling and well-understood failover, at the cost of a cluster-aware client and resharding operations. The vertical model gives you a simpler topology and fewer moving parts, at the cost of a larger blast radius per node and a hard ceiling at one machine’s resources. Neither is wrong. They suit different growth shapes.
The cost and sizing angle
License posture is the headline, but topology drives the bill. A horizontally scaled cluster spends money on coordination: more nodes mean more replicas, more inter-node traffic, and more operational surface to monitor. A vertically scaled instance spends money on a single large machine, which can be cheaper per gigabyte cached but concentrates risk. Map your growth curve before you pick.
If your cache fits comfortably in one big box and grows slowly, the vertical model usually wins on simplicity and cost. If your dataset grows unpredictably or must span availability zones for resilience, the clustered model earns its overhead. There is no universal answer here, only a question: do you expect to scale by adding cores or by adding nodes? Write that expectation into the ADR, because it is the assumption a future engineer will most want to revisit.
Migration and compatibility notes
Migration risk is mostly a function of how far your usage strays from core Redis. The migration path below applies to all three targets, with Valkey being the gentlest because it shares Redis’s lineage directly.
Start with an audit. Inventory every module you load, every Lua script you run, and any commands that touch persistence or cluster internals. For a Valkey move this audit is usually a formality — it is the same engine family, so scripts and data types transfer unchanged. For a Dragonfly move, the audit is the real work: check that each command and any module behavior you rely on is supported, since Dragonfly implements the common surface but not every Redis module.
The mechanical migration is familiar. Take an RDB snapshot, attach the new engine as a replica of your current primary, let it complete a full sync, then promote it and flip the application endpoint. Because all three speak the Redis replication protocol, this replica-and-promote pattern works across the board. Keep the old primary warm until you have verified keyspace counts and latency on the new one.
For caches specifically, you often skip replication entirely. A cache can be repopulated from the source of truth, so the cleanest migration is to stand up the new engine empty, point a slice of traffic at it, and let it warm naturally. If your caching layer fronts an LLM or vector workload, the semantics get subtler — our note on semantic caching architecture covers the parts a key-value migration does not.
One more compatibility nuance trips teams up: client libraries. Valkey ships its own client family, but the Redis clients you already use generally speak to it without change, since the protocol is shared. Dragonfly’s wire compatibility means standard Redis clients connect to it too. The friction is rarely the connection — it is the long tail of commands. Audit any use of cluster-management commands, introspection commands, or vendor-specific extensions, because those are where the three engines diverge most. A staging environment that replays a sample of production traffic against the candidate engine surfaces these gaps faster than reading compatibility tables ever will.
Trade-offs and gotchas
A few details bite teams during a switch. None are dealbreakers, but each deserves a line in your ADR.
Persistence semantics. All three support snapshotting and append-only logging, but the exact durability guarantees and fsync behavior differ in the fine print. Do not assume your old appendfsync tuning carries over byte-for-byte. Test a hard kill and confirm what survived.
Eviction policies. The LRU, LFU, and TTL eviction families exist across all three, but the approximations and sampling differ. If your cache depends on precise eviction behavior under memory pressure, validate it under load rather than trusting parity claims.
Lua and modules compatibility. Lua scripting transfers cleanly between Redis and Valkey. Against Dragonfly, test your scripts directly. Redis modules — including the search and JSON capabilities bundled into Redis 8 — are the least portable surface. A workload built on Redis Stack search does not lift cleanly onto Valkey or Dragonfly today.
License obligations. This is the gotcha that reaches outside engineering. Redis 8 under AGPLv3 triggers network copyleft: if you modify the source and offer it over a network, you may owe those modifications. Dragonfly’s BSL restricts offering it as a competing managed service until the conversion date. Valkey’s BSD-3 has effectively no such strings. Loop in whoever owns license policy before you commit; this is exactly the kind of clause that surfaces during due diligence.
Memory efficiency in practice. All three engines are memory-conscious, but how they spend bytes differs. Redis and Valkey share the same encodings and use small-object optimizatio
