A Redis primary that pins one core at 100% while the rest of the host sits idle is the usual reason teams look at Dragonfly. The licence is the usual reason they look at Valkey. Both questions changed this autumn. Redis Open Source 8.10.3 (26 October 2026) ships under your choice of RSALv2, SSPLv1, or AGPLv3, and Valkey 9.1.3 stays BSD 3-Clause. On 4 November 2026, Dragonfly v2.1 moved to a new source-available licence that allows 100 production vCPUs before a commercial licence is needed. Switching also has a cost: a Lua script can fail on Dragonfly with script tried accessing undeclared key, and a Redis 8 data file will not load into Valkey. This post compares the three and shows how to measure them on your own workload.
- Redis 8.x is RSALv2, SSPLv1, or AGPLv3 at your choice; Valkey is BSD 3-Clause; Dragonfly v2.1 and later is DSAL, free up to 100 production vCPUs including replicas.
- Redis 8 and Valkey execute every command on one main thread and use I/O threads for the network work. In Dragonfly, each thread owns a shard of the keyspace and executes its commands.
- Dragonfly gaps: no loadable modules, no
FUNCTION, Lua limited to declared keys by default, no cluster control plane, and AOF only as an experimental v2.1 mode. - Valkey reads Redis OSS 7.2 data files but not Redis 7.4 or later, so Redis 8 to Valkey needs a logical copy.
- Prove any move with memtier_benchmark and a replay of your own traffic, not vendor numbers.
Scope and review date: November 2026. This post covers Redis Open Source 8.10.3, Valkey 9.1.3, and Dragonfly v2.1, self-managed on Linux, with notes on Amazon ElastiCache, MemoryDB, and Dragonfly Cloud. Versions, flags, and licence terms were checked against vendor documentation, release notes, source, and licence files on 9 November 2026. The commands were not run in a lab, and every performance figure here is a vendor's own claim.
Which versions and licences apply in November 2026?
Redis 8.10.3 is the newest GA release; 8.12 is at release candidate 2. The Redis licences page says Redis Open Source 8.0 and later can be used under RSALv2, SSPLv1, or AGPLv3. Redis 7.4.x to 7.8.x remain RSALv2 or SSPLv1, and 7.2.x and earlier remain BSD 3-Clause. AGPLv3's network clause applies if you modify Redis and serve users over a network, so have legal review it.
Valkey 9.1.3 is the newest GA release; 9.2.0 is at release candidate 2. Its COPYING file is BSD 3-Clause.
Dragonfly v2.1 release notes say: "Starting from v2.1.0 the project moves from BUSL-1.1 to the Dragonfly Source-Available License (DSAL)." The DSAL text allows "a maximum of one hundred (100) vCPUs in Production Use", counted across all instances you and your affiliates run, replicas and standbys included. Non-production use is not limited. It also bars distributing Dragonfly as a standalone database or caching product and has no later conversion to an open source licence. Releases up to v2.0.2 stay under BSL 1.1; the v2.0.2 licence file names 1 November 2030 as the change date to Apache 2.0.
# Ask each server what it is
redis-cli -h cache-01 INFO server \
| grep -E '^(redis_version|server_name|valkey_version|dragonfly_version):'Interpretation: Valkey 9.1.3 reports redis_version:7.2.4 plus valkey_version:9.1.3. Dragonfly v2.1 reports redis_version:7.4.0 plus dragonfly_version. Tooling that enables features from redis_version alone will guess wrong on both forks.
A Dragonfly primary on a 32 vCPU node with two same-sized replicas uses 96 production vCPUs under the DSAL. Dragonfly's FAQ still described the BSL on 9 November 2026, so read the LICENSE.md in the tag you deploy.
How do Redis, Valkey, and Dragonfly use more than one core?
Redis 8 assigns each client to the I/O thread with the fewest clients. That thread reads the socket, parses the query, and writes the reply, but pull request 13695 is explicit that "all client commands must be executed on the main thread". Replica, MONITOR, and pub/sub connections stay on the main thread.
Valkey 8 and later works the same way at the top level: I/O threads read, parse, write, and poll for events, and the main thread executes commands after prefetching their keys. Valkey 9.1 changed how jobs reach the threads; our Valkey 9.1 guide covers it.
Dragonfly splits the keyspace into shards, and its shared-nothing design note says "Each database shard is owned and accessed by a single thread." A connection's thread hashes the key and sends a message to the owning thread, so data structures need no locks. Multi-key commands, transactions, and Lua scripts are coordinated across shards, at some CPU and latency cost.
Where commands execute in each engine
Redis and Valkey thread the network work; Dragonfly threads the data
What it means: extra cores help Redis and Valkey only until the main thread is busy executing. Dragonfly spreads execution, but pays a coordination cost on commands that touch several shards.
# redis.conf (Redis 8.10) or valkey.conf (Valkey 9.1), 8-core host
io-threads 6Interpretation: threading is off by default (io-threads 1). The shipped redis.conf suggests 7 threads on 8 cores and valkey.conf suggests 6. io-threads-do-reads no longer has any effect in either. Benchmark Redis or Valkey with threads on, or the comparison measures a setup nobody should run.
# Dragonfly: proactor_threads=0 (the default) starts one thread per core
dragonfly --proactor_threads=8 --maxmemory=48gb --dir=/var/lib/dragonfly
redis-cli -h cache-01 INFO server | grep -E '^(io_threads_active|thread_count):'Interpretation: Redis and Valkey report io_threads_active:1 when I/O threads are in use, and Dragonfly reports thread_count. On Redis 8, INFO threads adds one io_thread_N line per thread with its client count.
What breaks when you swap Redis for Valkey or Dragonfly?
Valkey was forked from Redis 7.2.4, and the Valkey migration guide treats Redis OSS 2.x to 7.2.x as compatible in protocol, configuration, and data files. The gap is what Redis added later: Redis 8 builds in its query engine, JSON, time series, probabilistic types, and vector sets. Valkey offers JSON, Bloom, search, and LDAP as modules in the valkey-bundle, with no time series module.
Dragonfly runs its own engine behind the Redis protocol. Its compatibility page lists MODULE LOAD, FUNCTION, FCALL, OBJECT ENCODING, WAITAOF, and most CLUSTER management subcommands as unsupported, and CLIENT TRACKING without BCAST or PREFIX. JSON is fully supported; search and Bloom partly. The page warns that "fully supported" does not mean identical behaviour.
Redis, Valkey, and Dragonfly side by side
Switch engines to see what changes for licence, threading, scale-out, and scripts
Redis 8.10
| Area | Redis 8.10 |
|---|---|
| Licence | RSALv2, SSPLv1, or AGPLv3 |
| Command execution | One main thread |
| Scale-out | Redis Cluster, 16,384 hash slots |
| Persistence | RDB snapshots (fork) and AOF |
| Extensions | Query engine, JSON, time series built in; modules loadable |
| Lua scripting | Lua 5.1; EVAL and FUNCTION |
| Managed on AWS | Not on ElastiCache (Redis OSS up to 7.1) |
Valkey 9.1
| Area | Valkey 9.1 |
|---|---|
| Licence | BSD 3-Clause |
| Command execution | One main thread |
| Scale-out | Valkey Cluster; atomic slot migration since 9.0 |
| Persistence | RDB snapshots (fork) and AOF |
| Extensions | Modules loadable; valkey-bundle adds JSON, Bloom, search |
| Lua scripting | Lua 5.1; EVAL and FUNCTION |
| Managed on AWS | ElastiCache (up to 9.1) and MemoryDB |
Dragonfly 2.1
| Area | Dragonfly 2.1 |
|---|---|
| Licence | DSAL: 100 production vCPUs, then commercial |
| Command execution | Every thread, on the shard it owns |
| Scale-out | Emulated cluster on one node; multi-node needs your own control plane |
| Persistence | Forkless snapshots; AOF experimental |
| Extensions | No module loading; JSON built in, search and Bloom partly |
| Lua scripting | Lua 5.4; declared keys only by default; no FUNCTION |
| Managed on AWS | Dragonfly Cloud (also GCP and Azure) |
Read the rows you use: a cache that only runs GET, SET, and EXPIRE sees few of these differences. Lua, modules, and cluster tooling are where migrations stall.
The Lua difference that bites first
Redis's Lua documentation says scripts should only touch keys passed in KEYS, but Redis does not enforce it. Dragonfly does: its scripting page returns script tried accessing undeclared key by default.
# Fails on Dragonfly by default: the script builds a key it did not declare
redis-cli -h df-01 EVAL "return redis.call('GET', 'user:' .. ARGV[1])" 0 42
# Fix 1 (portable): declare the key
redis-cli -h df-01 EVAL "return redis.call('GET', KEYS[1])" 1 user:42
# Fix 2 (Dragonfly only): allow it for one script, by SHA1
redis-cli -h df-01 SCRIPT FLAGS <sha1> allow-undeclared-keysInterpretation: fix 1 works on all three engines and in cluster mode. With allow-undeclared-keys, Dragonfly pauses other operations while the script runs, which gives back the throughput you moved for. Dragonfly also embeds Lua 5.4 rather than 5.1, so test scripts that rely on 5.1 behaviour.
How do clustering, replication, and failover compare?
Redis and Valkey share two patterns: Sentinel promotes a replica when a primary fails, and cluster mode spreads 16,384 hash slots across primaries that gossip and fail over among themselves. Valkey 9.0 added atomic slot migration and numbered databases in cluster mode (Valkey 9.0 announcement).
Dragonfly with --cluster_mode=emulated runs one node that answers CLUSTER SLOTS and CLUSTER SHARDS, so cluster-aware clients connect unchanged. With --cluster_mode=yes, the cluster mode page says Dragonfly "does NOT provide a control plane": you push the slot map to every node with DFLYCLUSTER CONFIG, nodes do not gossip, and failover comes from Dragonfly Swarm in Dragonfly Cloud or your own tooling.
Dragonfly's replication page says it supports the replication protocol of Redis OSS up to version 6.2, so it can replicate from such a primary during a migration. Its Kubernetes operator promotes a new master when replicas is above 1, and a migration guide shows Redis Sentinel promoting a Dragonfly replica.
# Dragonfly as a replica of an existing Redis primary
redis-cli -h df-01 REPLICAOF 10.0.1.10 6379
redis-cli -h df-01 INFO replication | grep -E '^(role|master_link_status):'
# At cutover
redis-cli -h df-01 REPLICAOF NO ONEInterpretation: wait for master_link_status:up before planning the cutover. A Redis 7.x or 8.x source is outside the documented range, so rehearse it; if the link does not come up, use a snapshot or a logical copy.
How do persistence and backups compare?
Redis and Valkey fork a child for RDB snapshots, which needs memory headroom for pages that change during the snapshot, and append writes to an AOF governed by appendfsync. Our RDB vs AOF guide covers those settings.
Dragonfly takes forkless point-in-time snapshots using per-shard epochs (snapshotting design). With df_snapshot_format=true, the default, it writes one file per shard; set it to false for one Redis-compatible RDB file. Its AOF page still said "Currently, Dragonfly does not support AOF" on 9 November 2026, while the v2.1 release notes add an experimental AOF mode. Plan Dragonfly recovery around snapshots plus replicas until that mode is documented as stable.
# Dragonfly v2.1: snapshot every 15 minutes, timestamped file names
dragonfly --dir=/var/lib/dragonfly --dbfilename="dump-{timestamp}" \
--snapshot_cron="*/15 * * * *"Interpretation: dump-{timestamp} is the default name, set here so the restore runbook names it. The recovery point is the snapshot interval unless a replica survives.
Valkey cannot load RDB files from Redis 7.4 or later. Dragonfly v2.0 added loading of Valkey 9 RDB files; its docs do not say whether Redis 8 files load, so test with a copy of your own.
What do the vendors claim about memory and throughput?
Every number below is the vendor's own, on hardware and baselines the vendor chose. None is a JusDB result.
| Vendor claim | Source | Baseline |
|---|---|---|
| Dragonfly: 25x the throughput of a single Redis process, 3.8M QPS on c6gn.16xlarge | Dragonfly README | One Redis process, not Redis 8 with I/O threads |
| Dragonfly: 30% more memory-efficient than Redis when idle, no visible growth during a snapshot | Dragonfly README | About 5 GB of test data |
| Valkey 8.0: 360K to 1.19M requests per second on C7g.16xlarge with 8 I/O threads | Valkey blog | Valkey 7.2, 512-byte SET |
| Valkey 9.1: strings under 128 bytes use 20% less memory | ElastiCache engine versions | ElastiCache Valkey 9.0 |
# After loading the same dataset into each engine
redis-cli -h HOST DBSIZE
redis-cli -h HOST INFO memory | grep -E '^(used_memory|used_memory_rss):'Interpretation: used_memory_rss divided by DBSIZE gives bytes per key including allocator overhead. Use your real key and value shapes.
How do you benchmark your own workload with memtier_benchmark?
memtier_benchmark (2.5.2 is the newest tag) drives all three engines. Run it from a separate machine in the same zone, and match production: the read to write ratio from INFO commandstats, real value sizes, a skewed key distribution if you have hot keys, and your real connection count and pipeline depth.
# 1. Prefill: write every key in the range once
memtier_benchmark -s 10.0.2.15 -p 6379 --ratio=1:0 --requests=allkeys \
--key-pattern=P:P --key-minimum=1 --key-maximum=5000000 \
--data-size=512 --threads=4 --clients=25 --hide-histogram
# 2. Test: 1 write to 4 reads, Gaussian hot spot, three 5-minute runs
memtier_benchmark -s 10.0.2.15 -p 6379 \
--threads=8 --clients=25 --pipeline=1 \
--ratio=1:4 --data-size=512 \
--key-minimum=1 --key-maximum=5000000 --key-pattern=G:G \
--test-time=300 --run-count=3 --distinct-client-seed \
--print-percentiles=50,99,99.9 --hide-histogram \
--json-out-file=candidate-run.jsonInterpretation: check DBSIZE after step 1. Step 2 opens 200 connections. Run both against every engine on the same instance type, add --cluster-mode for a cluster target, and compare p99 and p99.9 latency at your target throughput.
Reading a memtier_benchmark summary
Illustrative output: the layout memtier_benchmark prints, with placeholders instead of numbers and columns trimmed
Read Misses/sec first: a high miss rate means the prefill did not cover the key range and the run measured empty reads. The real table also has Hits/sec, Avg. Latency, and KB/sec columns.
Which managed offerings exist for each engine?
Amazon ElastiCache lists Valkey 7.2 through 9.1 and "all Redis OSS versions 7.1 and before" (engine versions), so Redis 8 is not offered. The pricing page states Valkey is priced 20% lower than Redis OSS on node-based clusters and 33% lower on Serverless. AWS documents an in-place upgrade from Redis OSS to Valkey that keeps the endpoint, with a write pause during a failover that "lasts a few seconds" from Redis OSS 5.0.6. The only documented rollback is Valkey 7.2 to Redis OSS 7.1.
# AWS's documented cross-engine upgrade of a replication group
aws elasticache modify-replication-group \
--replication-group-id myReplGroup \
--engine valkey \
--engine-version 9.0Interpretation: with a custom parameter group, also pass a Valkey group with the same static values in --cache-parameter-group-name. Going straight to 9.x leaves no documented rollback, so take a snapshot first.
Amazon MemoryDB is Valkey- and Redis OSS-compatible and keeps data in a Multi-AZ transaction log. Dragonfly Cloud runs on AWS, Google Cloud, and Azure, with a bring-your-own-cloud option. Redis Ltd. offers Redis Cloud and Redis Software for teams that want Redis 8 from its vendor.
When does a migration pay off, and how do you test one?
Dragonfly pays off when one primary is bound by command execution even with I/O threads on, the dataset fits one large node, the alternative is reworking the application for Redis Cluster, your command inventory fits Dragonfly's supported list, and the fleet fits 100 vCPUs or a licence budget. Valkey pays off when the licence is the problem, when you run Redis OSS 7.2 or earlier, or when the ElastiCache price difference matters. Stay on Redis 8 if you use its query engine, time series, or vector sets.
# Per-thread CPU of the server (use valkey-server for Valkey)
top -H -p "$(pidof redis-server)"
redis-cli -h redis-prod SLOWLOG GET 10Interpretation: one thread near 100% with idle I/O threads means execution is the limit, which Dragonfly or sharding addresses. Large SLOWLOG entries mean the workload is the limit, and any engine runs those commands slowly. Our Redis performance tuning guide covers those fixes.
Evaluate a drop-in replacement with replay testing
Eight steps; only step 8 pauses writes
-
Inventory commands, scripts, and modules
List every command production runs, plus every Lua script and module.
redis-cli INFO commandstats \ | cut -d: -f1 | sort -
Check them against the target
Use Dragonfly's compatibility page or Valkey's command reference. Rewrite scripts that build key names.
-
Build a candidate with real data
Dragonfly:
REPLICAOFor a snapshot. Valkey: replication only from Redis 7.2 or earlier; later versions need a logical copy.redis-cli -h candidate REPLICAOF \ 10.0.1.10 6379 -
Capture a short traffic sample
Run
MONITORfor seconds in a quiet period: Redis's docs show oneMONITORclient cutting throughput by more than 50%. The file holds real keys and values.timeout 10 redis-cli -h redis-prod \ MONITOR > monitor.txt -
Replay against old and new
Send the same file to both engines, then compare
INFO errorstats.memtier_benchmark -s candidate \ --monitor-input=monitor.txt \ --command="__monitor_line@__" \ --test-time=120 --hide-histogram -
Load test at target throughput
Run the shaped memtier_benchmark test and record p99 and p99.9 latency.
-
Drill failover and restore
Kill the candidate primary, time promotion and client reconnects, and restore a snapshot onto a fresh node.
-
Cut over with the old primary intact
Write pausePause writes, let the candidate catch up, promote it, and repoint clients. Leave the old primary untouched.
redis-cli -h candidate REPLICAOF NO ONE
Rollback point: until clients write to the new primary, rollback is repointing them. After that, new writes exist only on the new engine, so decide before cutover how you would copy them back.
Frequently asked questions
Is Dragonfly open source in 2026?
No. Releases up to v2.0.2 use the Business Source License 1.1, which is source-available rather than OSI open source. From v2.1, released 4 November 2026, Dragonfly uses the Dragonfly Source-Available License, which allows up to 100 vCPUs in production, replicas included, before a commercial licence is required. Non-production use is not limited.
Is Redis 8 open source again?
Partly. From Redis 8.0, Redis Open Source can be used under your choice of RSALv2, SSPLv1, or AGPLv3, and AGPLv3 is an OSI-approved licence with a network clause that matters if you modify Redis and serve users over a network. Redis 7.4 to 7.8 stay RSALv2 or SSPLv1, and Redis 7.2 and earlier stay BSD.
Can I migrate from Redis 8 to Valkey with REPLICAOF?
No. The Valkey migration guide says Redis Community Edition 7.4 and later produce data files that are not compatible with Valkey, and replication sends the same format. Redis OSS 7.2 and earlier can replicate into Valkey directly. From Redis 7.4 or 8.x, copy the data logically, key by key, through the command layer.
Is Dragonfly faster than Valkey or Redis?
It can be on large hosts, because Dragonfly executes commands on every core while Redis and Valkey execute on one main thread. The published comparisons are vendor benchmarks with vendor-chosen baselines. Run memtier_benchmark on your own instance type and data, with I/O threads enabled on Redis or Valkey, and compare p99 latency at your target throughput.
Key takeaways
- Check licences per version: Redis 8.x offers RSALv2, SSPLv1, or AGPLv3; Valkey is BSD 3-Clause; Dragonfly v2.1 is DSAL with a 100 production vCPU limit that counts replicas.
- Redis and Valkey thread the network work and execute on one main thread; Dragonfly executes on every thread. Compare them with I/O threads enabled.
- Undeclared Lua keys,
FUNCTION, modules, and cluster tooling are where Dragonfly moves stall. Inventory them first. - Valkey reads Redis 7.2 data, not 7.4 or 8.x data; Dragonfly documents Redis replication up to 6.2. Rehearse the copy for your exact source version.
- Prove a migration with a memtier_benchmark load test, a traffic replay, and a failover drill.
Evaluate Dragonfly or Valkey with JusDB
JusDB's Dragonfly consulting team can review your command inventory, Lua scripts, and topology against Dragonfly's compatibility list, and help plan and run a replay test before any production change. If Valkey fits better, our Valkey migration team can plan the copy method for your Redis version, including the logical copy that Redis 7.4 and later need.
Bring your INFO commandstats output, engine versions, topology, and CPU and memory graphs from a busy week. Your team approves every production change.