Redis, Valkey, or Dragonfly: revisit the choice before you treat them as the same cache

If your service already uses Redis, the name on the port has not changed. The product behind that name has. Treating Redis, Valkey, and Dragonfly as three labels for one cache is the habit worth unlearning.

This is the first note in a series. It is not a benchmark. Vendor speed claims need their own post, with the hardware and the workload written down. Today the job is smaller and more useful: know what each project is, what a dump file will and will not load, and which licence you are actually accepting when you ship.

A short version you can take to a standup

Redis 7.2 and older stayed BSD-3-Clause. From Redis 7.4 (20 March 2024) new Redis builds moved to RSALv2 or SSPLv1. Redis 8, generally available on 1 May 2025, added AGPLv3 as a third option. It did not put BSD back.

Valkey was announced on 28 March 2024 by the Linux Foundation. It continues from Redis OSS 7.2.4, still under BSD-3-Clause. As of the Valkey download page checked on 5 October 2026, the current line is 9.1.2 (1 September 2026).

Dragonfly is an in-memory datastore from DragonflyDB, Ltd., under the Business Source License 1.1, not BSD and not AGPL. Many Redis commands work. Several important ones do not, and its cluster story is not Redis Cluster.

If you only run an unmodified cache inside your own app, read the licence section once and then test the migration, not the marketing page. If you sell a datastore, or you offer Redis as a service, stop and read the licence with your own counsel. This post is not legal advice.

What Redis actually changed

On 20 March 2024 Redis wrote that, starting with Redis 7.4, the software would be dual licensed under RSALv2 or SSPLv1, and would no longer be distributed under BSD-3-Clause. Older versions stay on BSD. Redis said the change is not retroactive.

Their stated reason is commercial, and it is worth reading in their words rather than in a recap. They wrote that “the majority of Redis’ commercial sales are channeled through the largest cloud service providers, who commoditize Redis’ investments and its open source community.” In the same FAQ they said that moving the licence lets Redis “better manage commercial uses of our source code,” and that organisations offering products that compete with Redis would no longer get new source free of charge. They also wrote, plainly, that Redis is no longer open source under the OSI definition. Neither RSALv2 nor SSPLv1 is OSI approved.

RSALv2 limits how you commercialise the software and how you offer it as a managed service. SSPLv1, if you offer the software as a service, asks you to release your modifications and the source of the management stack under SSPL. That is a much wider obligation than “keep the copyright notice.”

On 1 May 2025 Redis 8 went GA and added AGPLv3 as a third licence option, alongside RSALv2 and SSPLv1. Redis described this as an added choice, not a return to the old terms. The free product was renamed from Redis Community Edition to Redis Open Source. Rowan Trollope’s post says the March 2024 move hurt the relationship with the community, because SSPL is not OSI approved, and that AWS and Google now maintain their own fork. That fork is Valkey.

The licence table on redis.io, as checked for this post, lines up like this.

  • Redis 7.2 and earlier: BSD-3-Clause.
  • Redis Community Edition 7.4 (the page also covers 7.4.x through 7.8.x): RSALv2 or SSPLv1.
  • Redis Open Source 8.0.0 and later: RSALv2 or SSPLv1 or AGPLv3.

Redis 8 also pulled JSON, time series, probabilistic types, and the query engine into the main open source build. Those used to live in a separate stack. That is a product change, not only a legal one. If your runbook still says “install Redis, then add modules,” revisit it against the version you actually run.

Valkey is the BSD line, not a rename of Redis 8

The Linux Foundation announced Valkey on 28 March 2024. The project is under open governance at the Foundation, on BSD-3-Clause, continuing development from Redis 7.2.4. The first named supporters were Amazon Web Services, Google Cloud, Oracle, Ericsson, and Snap. Madelyn Olson (AWS, previously a Redis maintainer) is named as co-creator, with Ping Xie (Google Cloud) and Viktor Söderqvist (Ericsson) among the people called out in that release. A follow-up on 16 April 2024 added Aiven, Alibaba Cloud, Chainguard, Heroku, Huawei, Percona, and Verizon, and shipped 7.2.5-rc1. The first GitHub tag, 7.2.4-rc1, says it is based on OSS Redis 7.2.4.

Two facts from Valkey’s own migration notes matter more than the logo.

First, protocol compatibility is real for the old line. Valkey speaks RESP2 and RESP3. Existing Redis clients connect without an application code change. INFO still reports redis_version:7.2.4. The fields that tell you the truth are server_name and valkey_version. If your dashboard keys off redis_version alone, it will lie to you after the move.

Second, data files stop lining up at Redis 7.2. Valkey can read data from Redis OSS 7.2 and earlier. Redis Community Edition 7.4 and later write data files Valkey does not treat as compatible. A restore drill from a Redis 7.4 or Redis 8 dump into Valkey is not a formality. Do it on a copy, with the real RDB or AOF, before you announce a cutover.

Valkey 8.0.0 (15 September 2024) describes itself as fully compatible with Redis OSS 7.2.4, and it adds two engine changes of its own: asynchronous I/O threading, and a dual channel for full sync replication. Redis 8 later wrote about its own I/O threads and a two-stream replication design. Those are separate implementations. Do not merge them into one feature in a design doc just because the sentences look similar.

There is a packaging difference you will feel in application code. Redis 8 ships JSON and several other types in the main server. Valkey JSON is a separate official module, documented for Valkey 8.0 and above, and you load it yourself. If a service uses RedisJSON commands, “same client, same port” is not the whole migration.

Valkey 9.0 (21 October 2025) documents atomic slot migration with CLUSTER MIGRATESLOTS, separate from the older CLUSTER SETSLOT flow. The 9.1 line started on 19 May 2026. Current patch levels on the download page, all dated 1 September 2026, are 9.1.2, 8.1.10, and 7.2.14. Pick the line your change window can actually track. Running 7.2 forever because it feels familiar is its own risk.

Dragonfly is a different server that speaks a lot of Redis

DragonflyDB, Ltd. builds Dragonfly. Oded Poncz and Roman Gershman are the co-founders named on the company page. The server is in memory, and it aims at Redis and Memcached workloads. It is not a fork of Redis 7.2, and it is not under BSD.

The licence in the repository is Business Source License 1.1. The licensor is DragonflyDB, Ltd. The change date in the licence file is 1 November 2030, after which that version’s change licence is Apache-2.0. The text also converts on the earlier of that date or the fourth anniversary of the first public distribution of that version. Until then, the additional use grant allows use as part of your own product or service, provided that product is not itself an in-memory data store, and provided you do not offer the licensed work as a competing hosted or managed service. If you are building a cache inside your own application, that grant may cover you. If you are building a datastore product, it does not. Read the current licence file, not a screenshot from a talk.

Architecture, from their snapshotting docs: Dragonfly uses a shared-nothing design, and each shard thread serialises its own data. Snapshots are forkless and point in time. One export path is a Redis-compatible RDB. That is useful. It is not the same as “Redis persistence, including AOF rewrite, behaves the same.” BGREWRITEAOF is listed as unsupported.

Their command compatibility page is the page to keep open. It says that “fully supported” does not mean byte-for-byte identical behaviour. The table I checked was verified by them against Dragonfly v2.0.0 and Redis 8.6.4. Unsupported commands on that table include FCALL and FUNCTION * (Redis functions), MODULE LOAD, MIGRATE, BGREWRITEAOF, and most cluster admin commands: CLUSTER ADDSLOTS, CLUSTER MEET, CLUSTER SETSLOT, CLUSTER FAILOVER, ASKING, and others. CLUSTER INFO, CLUSTER KEYSLOT, CLUSTER NODES, CLUSTER SHARDS, and CLUSTER SLOTS are listed as fully supported.

Their benchmark document still describes Dragonfly as a drop-in replacement for Redis 6.x and Memcached. Their about page says it is fully compatible with the Redis ecosystem and needs no code changes. Those two sentences are not the same claim. The command table is the one that will match production.

Replication is primary and replica, through REPLICAOF and ROLE. The docs say Redis-to-Dragonfly replication supports the data structures and replication protocol of Redis OSS up to version 6.2. Internals differ from Redis replication. Do not point a Redis 7 or Redis 8 replica setup at Dragonfly and assume the backlog behaves.

Cluster mode needs the same care. If --cluster_mode is unset, Dragonfly emulates a single-shard cluster so a Redis Cluster client can talk to one node. Multi-shard mode is a data plane. Nodes do not gossip to learn membership. Failover, rebalancing, and health monitoring are not inside the server. Dragonfly points that control plane at its cloud product, Dragonfly Swarm. Multi-shard mode supports only database 0. Configuration uses DFLYCLUSTER on an admin port. Moving a self-managed Redis Cluster onto multi-shard Dragonfly is an architecture change, not a package swap.

How to choose, without a winner

There is no general ranking that survives contact with your workload. Use the constraints you already have.

You run Redis as an internal cache or session store, and you do not sell a competing datastore. Redis’s own FAQ says most community users, including people who host it for themselves, are not the target of the competitive-offering rule. Valkey under BSD-3-Clause is the permissive path if your company policy says “OSI approved, or a known permissive licence, and we keep the copyright notice.” Dragonfly’s grant can fit a cache inside your own product when that product is not itself an in-memory datastore and you are not offering Dragonfly as a service. Confirm the current grant text before you standardise on it.

You embed the server in a product you sell. BSD Valkey, and Redis 7.2 or older, allow a proprietary product with attribution. Redis 8 asks you to pick RSALv2, SSPLv1, or AGPLv3. Those are different obligations, especially if users reach the software over a network or if you offer it as a service. Dragonfly’s grant refuses the case where your product is an in-memory data store, even when you call it your own product. This is the point where a blog post should stop and a lawyer should start.

You offer Redis-compatible hosting to other people. RSALv2, SSPLv1, and Dragonfly’s BSL all restrict this. Valkey’s BSD-3-Clause does not. Redis wrote a separate note for managed service providers on 29 March 2024. If this is your business, that note and the current licence page outrank any comparison table.

Clients. Redis says the client libraries it maintains stayed under open source terms. Its licence table lists node-redis and ioredis as MIT, and hiredis as BSD-3-Clause. Valkey’s migration doc says existing Redis clients work, RESP2 and RESP3, with no application change. Dragonfly works with many of those clients, including a Redis Cluster client against emulated single-shard mode. “The client connects” is not “every command your code sends is supported.” Grep for FUNCTION, FCALL, MIGRATE, MODULE, and CLUSTER SETSLOT before you call it compatible.

What you give up in each direction.

  • Redis 7.4 or 8 to Valkey: 7.4 and later dump files are not compatible. Redis 8 types that live in the core server may need a Valkey module, or may not exist there yet. You also leave Redis Ltd. builds and their tooling.
  • Redis to Dragonfly: Redis functions, MODULE LOAD, MIGRATE, most cluster admin commands, Redis Cluster’s own control plane, identical command behaviour, and Redis replication newer than OSS 6.2 as documented. You also accept BSL until the change date for the version you run.
  • Valkey, or old BSD Redis, to Redis 8: you gain the bundled query engine and the types Redis pulled into core, and you accept RSALv2, SSPLv1, or AGPLv3.

What to practise this week

Pick one non-production copy of the data, not a diagram.

  1. Print INFO server and write down redis_version, and if present valkey_version and server_name. Do this on every environment, not only production.
  2. Note the exact binary and the licence that binary was built under. A container tag that still says redis:latest is not a decision.
  3. If Valkey is the candidate, restore a real Redis OSS 7.2 dump, then try a dump from whatever version you run now. Record which one loads.
  4. If Dragonfly is the candidate, run your command list against their compatibility table, then against a staging node. Pay extra attention to functions, modules, MIGRATE, and anything that issues CLUSTER SETSLOT.
  5. If the service is sold, or offered as a managed cache, send the licence page to counsel with the version number. Do not settle that in a Slack thread.

Sahil’s earlier note on this site already covers how a Node service uses Redis for cache, expiry, pub/sub, sessions, and rate limits. This post does not repeat that. The application patterns stay useful. The server you point them at is what changed.

What this series will do next

The next note will take performance claims one at a time. Dragonfly publishes a benchmark write-up (their v1.15.0 run, on AWS, with memtier). Redis publishes its own figures for Redis 8, including I/O threads, against Redis’s own baseline. Those numbers are the vendor’s run. They are not a three-way test on your instance size, and a “25x” line on a marketing page is not a measurement. We will write the method, the machine, and the limit next to any figure, or we will leave the figure out.

Until then, the useful revisit is the boring one. Same port does not mean same server, same dump, or same licence.

Sources

comments powered by Disqus

Releted Posts

How Redis Helps to Increase Service Performance in NodeJS

How Redis Helps to Increase Service Performance in NodeJS

In modern backend applications, performance optimization is crucial for handling high traffic efficiently. Typically, a backend application consists of business logic and a database.

Read more
MongoDB 8.0 Performance is 36% higher, but there is a catch...

MongoDB 8.0 Performance is 36% higher, but there is a catch…

TLDR: If your app is performance critical, think twice, thrice before upgrading to MongoDB 7.0 and 8.0. Here is why…

Read more
Optimizing MongoDB Performance with Indexing Strategies

Optimizing MongoDB Performance with Indexing Strategies

MongoDB is a popular NoSQL database that efficiently handles large volumes of unstructured data. However, as datasets grow, query performance can degrade due to increased document scans.

Read more