Valkey vs Redis vs Dragonfly in 2026: forkless BGSAVE, INCREX and which one takes the cache slot

Valkey 9.2  INCREX key [NX|XX] [EX s|PX ms|EXAT ts|PXAT ms-ts] [BYINT n|BYFLOAT f]
Redis 8.8   INCREX key [BYFLOAT f|BYINT n] [LBOUND lo] [UBOUND hi] [SATURATE]
                   [EX s|PX ms|EXAT ts|PXAT ms-ts|PERSIST] [ENX]

Why does a busy Redis reclaim expired memory faster than an idle one?

A busy Redis reclaims expired keys faster because every read that touches a dead key deletes it on the spot, and a fast expiry cycle is tried on every pass of the event loop, so more traffic means more passes. An idle server relies on the background cycle, which runs ten times a second and keeps sampling 20 keys with a TTL at a time while more than 10% of them have expired, up to 25% of CPU time (expire.c in 8.10.2).

Reclaim times after a mass expiry, Redis 8.10.2 on 2 vCPU, and managed Valkey 9 on 1 vCPU for the last bar. Chart from redis-expiry-lag by Kalin Dimitrov, MIT licence.

In a test posted on 2 October, five million keys given one EXPIREAT deadline held 810 MB for 22.8 seconds on an idle Redis 8.10.2. Raising hz from 10 to 100 cut that to 13.7 seconds; one client reading with SCAN cut it to 5.1. On DigitalOcean's managed Valkey 9 with 1 vCPU, one million keys took 7.5 seconds, against 3.2 locally.

The lag turns into errors under Redis's default noeviction policy. With maxmemory set slightly above a 4 million key dataset, writes were refused with an OOM error for 2.5 seconds after the expiry, while the same test under allkeys-lru lost no live keys. Two defaults differ here: Valkey 8 and later free expired values in the background (lazyfree-lazy-expire yes), while Redis 8.10.2 frees them on the main thread. For any of the three stores used as a cache, set an allkeys-lru or allkeys-lfu policy and add jitter to expiry times.

Dragonfly's throughput numbers come from Dragonfly

The only hard Dragonfly numbers this month are Dragonfly's own. The Redis vs Dragonfly post of 6 October published no benchmark numbers: the author pointed an existing connection string at Dragonfly, the clients worked, and he lists the gaps he found in the docs and the issue tracker. Dragonfly's head-to-head with Valkey 9.0, published on 17 June 2026, is vendor-run.

On eight cores, reads are within 5%. The gap is writes, write tail latency and anything above eight cores: doubling to 16 vCPU took Valkey from 548K to 599K writes a second and Dragonfly to 1,563K. Dragonfly's snapshots never fork, and it has no AOF. Its compatibility table marks about 70 commands unsupported, among them FUNCTION, FCALL and MODULE LOAD, and does not list INCREX. Lua scripts that touch undeclared keys are rejected unless you set allow-undeclared-keys.

The licence is BSL 1.1: production use is allowed inside your own product, as long as that product is not itself an in-memory data store and Dragonfly is not offered as a service to others. Versions from v1.40 become Apache 2.0 on 1 November 2030 or four years after their release, whichever comes first, which for every release so far is the four-year date (LICENSE.md). Since v2.0.2 of 7 October, the daily version check also sends anonymous deployment details such as architecture, cloud provider and thread count.

What switching between them costs

Switching cost depends on direction. Valkey reads Redis RDB files up to 7.2, the version it forked from, but with the default rdb-version-check strict it refuses RDB versions 12 to 79, and Redis 8.10.2 writes version 15 (rdb.h). Moving a Redis 8 dataset to Valkey is a logical migration: reload from the source of truth, replicate with a tool, or copy key by key.

For a cache, a reload is usually the whole migration: point the clients at the new host and let it warm. The cost sits in the commands you use. Redis 8 bundles JSON, search, time series, probabilistic types and vector sets, with nothing extra to install; on Valkey, JSON, search and bloom filters are separate modules (valkey-json, valkey-search, valkey-bloom). INCREX does not port between the two. Dragonfly v2.0.0 loads Valkey 9 RDB files, and moving to it means checking your scripts and transactions against its compatibility table.

On managed hosting, ElastiCache prices Valkey 20% below Redis OSS on nodes and 33% below on Serverless, with a 100 MB Serverless minimum instead of 1 GB. Memorystore charges the same for both, so there the choice is features, not price.

Pick Valkey if, pick Redis if, pick Dragonfly if

Pick Valkey if:

• You want a BSD-licensed store and the Redis API you already know.
• You run on ElastiCache, where it is 20 to 33% cheaper than Redis OSS.
• You persist snapshots on a box with little memory headroom and can wait for 9.2's GA, targeted for 15 November.
• Your rate limiter can live with a sliding window, or you set EXAT yourself.

Pick Redis if:

• You want JSON, search, vector sets or time series bundled, with nothing extra to install.
• You want a fixed-window INCREX with ENX and an upper bound today, in a stable release.
• You are already on Redis 8 with RDB backups you need to restore, since Valkey's default rdb-version-check strict refuses them.

Pick Dragonfly if:

• One node has to take more writes than about eight cores of Valkey, and you would rather scale up than run a cluster.
• Write tail latency matters more to you than the full command set.
• You do not use AOF, FUNCTION or modules, and the BSL terms fit your product.

Key numbers

• 354 MB to 9.9 MB: memory rise during a BGSAVE of 1.1 GB, fork() against forkless, Valkey 9.2.0-rc1, 4 October 2026 (Georgiev).
• 22.8 seconds: time an idle Redis 8.10.2 held 810 MB after five million keys expired at once, 2 October 2026 (redis-expiry-lag).
• 20%: ElastiCache node discount for Valkey against Redis OSS, 33% on Serverless, pricing checked 14 October 2026 (AWS).
• 816K against 548K: writes per second, Dragonfly against Valkey 9.0 on an 8 vCPU Graviton node, vendor-run, 17 June 2026 (Dragonfly).
• 15 November 2026: Valkey 9.2.0 GA target, after rc1 on 16 September 2026 (release plan).