Valkey or Redis? The two key-value servers compared

The short answer

Pick Valkey if you want a cache, session store or job queue under a permissive open-source licence, run by a foundation rather than one company: for those jobs it was as fast as Redis, used slightly less memory for plain strings and wrote snapshots faster. Pick Redis if your app needs JSON documents, full-text search, time series or vector sets in the same server, which the official Redis image has built in, and the AGPLv3 suits you.

What we tested

We installed both on the same fresh Melonslab VC-P Alloy (2 vCPU, 8 GB) with Debian 13, by following our guides Valkey server with rootless Podman and Redis server with rootless Podman step by step. Each ran under a user of its own, with the configuration from its guide: the default user off and a login per app, maxmemory 4gb with noeviction, and the AOF with appendfsync everysec plus hourly snapshots. The only change was the port: Valkey on 127.0.0.1:6379 and Redis on 127.0.0.1:6380, so both could run at once. The server had no WireGuard, so we left out the second PublishPort line, as both guides allow.

Then, with one server idle while we tested the other:

• Throughput, with the same two tools against both: redis-benchmark 8.10 (50 clients, SET and GET over 100,000 keys, values of 100 bytes, 1 KB and 16 KB, without and with a pipeline of 16) and memtier_benchmark 2.5.2 (50 clients, one SET per ten GETs and one per one GET, 100-byte and 1 KB values). Each run three times through the published port, as an app on the server connects, and twice from inside each container's own network, without Podman's port forwarding. We report the median.
• io-threads: the same runs again with io-threads 2.
• Memory: one million keys of three kinds, and ten million 100-byte strings with random content, about 1.1 GB.
• Persistence: snapshot, AOF rewrite and load times for those ten million keys, and the backup command from each guide.
• Clients: redis-py 8.1.0 and valkey-py 6.2.0 against both servers, over RESP2 and RESP3, and node-redis 6.3.0 against both.

Finally we rebooted the server and checked that both came back with their data.

The numbers

Memory is what each server reported as used_memory for the data, and podman stats for the idle containers, a few minutes after a reboot. The whole server, with both running and Caddy from the Podman guide, used about 520 MB.

Speed

For the work most apps give them, short reads and writes, we could not tell the two apart. Operations per second, the median of our runs, with the default io-threads 1:

The same test often varied by 10 to 20 % between runs, on the same server, so differences smaller than that are noise. Redis was a little ahead in most memtier runs, Valkey in some of the redis-benchmark ones. The p99 latency, in the memtier run without a pipeline, was 5.1 ms for Valkey and 4.7 ms for Redis, with the benchmark tool itself on the same two vCPUs.

Two things mattered far more than the choice of server:

• Podman's port forwarding halved the throughput of both without a pipeline. Apps that connect through 127.0.0.1 or WireGuard go through it, as in our guides. Up to around 20,000 operations a second, which is a lot for most apps, it does not matter.
• Pipelining, sending many commands before waiting for answers, gave both four to eight times as many operations. Most client libraries can do it.

io-threads spreads the network work over more threads, and is meant for servers with more cores. On our 2 vCPUs, io-threads 2 made things worse without a pipeline: Valkey dropped to between half and three quarters of its speed, and Redis to between 75 and 100 %, since the threads compete with the benchmark and with Podman for the same two cores. With a pipeline of 16, Valkey gained up to 27 % in the memtier runs and lost up to a third in others, and Redis lost 14 to 25 %. On a server with two cores, leave io-threads out, as both guides do.

Memory

Both keep everything in memory, so this is what decides how much data fits under maxmemory. For one million strings or integers the two were within 10 % of each other. With ten million keys, Valkey used 160 MB less, 1.34 GB against 1.50 GB. Valkey's release notes credit a more compact table for the keys and, in 9.1, less overhead for short strings. For hashes, Redis 8.10 was ahead, with 135 MB for a million hashes against 150 MB; its release notes name a new compact hash encoding in 8.10.

At idle, both used about 10 MB.

Persistence and backups

Both write the same kind of snapshot and the same AOF, and the files came out the same size. Valkey wrote the snapshot of our 1.1 GB of data in 18 seconds and Redis in 28; in a second test with easily compressed values, 12 and 17 seconds. Both took 26 seconds to load the data at start, and answered LOADING until then. A restart took about 38 seconds in all for both, since each saves a final snapshot when it stops.

Each guide's nightly backup asks the server for a snapshot with --rdb. For the 1.1 GB, that took 23 seconds with Valkey and 22 with Redis, while the server kept answering. With nothing changing during the snapshot, the copy made by fork stayed around 1 MB for both.

Both came back by themselves after a reboot, with all their keys.

The snapshot formats have drifted apart since the fork. We tried each server's snapshot in the other: Redis 8.10 loaded Valkey's, which held only plain keys, but Valkey 9.1 refused Redis's with Can't handle RDB format version 15. To move from Redis to Valkey, copy the keys with a tool that reads from one and writes to the other, not dump.rdb.

Clients

Valkey answers as Redis 7.2.4 in INFO, plus its own valkey_version, so libraries written for Redis connect without changes. In our tests:

• redis-py worked against both, over RESP2 and RESP3: strings, counters, pipelines, transactions, hashes with field expiry, streams, Lua scripts, SCAN and pub/sub. Its JSON commands worked only against Redis.
• valkey-py, the Valkey project's fork of redis-py, worked against both too, and its JSON commands also worked against Redis. It has no hexpire() method yet, though the command works when you send it yourself.
• node-redis 6.3.0, the client Redis maintains, did everything against both, field expiry included, except JSON against Valkey.

If an app checks the version for a feature that came after Redis 7.2, it may see 7.2.4 from Valkey and turn the feature off, even when Valkey has it.

Features

The core commands are the same: both have strings, lists, sets, sorted sets, hashes with field expiry, streams, pub/sub, Lua and ACLs. The rest differs. We compared the command lists of the two servers: with subcommands, Redis had 669 and Valkey 399.

Redis 8 puts its former modules in the official image and loads them at start: JSON documents (JSON.*), the search and query engine (FT.*), time series (TS.*), and Bloom and cuckoo filters, count-min sketch, top-k and t-digest. It also has vector sets (V*) for similarity search, a new array type (AR*), HOTKEYS for finding the busiest keys, and incremental backups (BACKUP). In our test, the app's login stored a JSON document and found it with a search index, as the Redis guide shows.

Valkey has none of those in its own image. Its additions are mostly for running it: COMMANDLOG for slow and large commands, DELIFEQ for safe lock release, logins limited to certain databases, and, in cluster mode, numbered databases, atomic slot migration and CLUSTERSCAN. For the extras, the Valkey project publishes a second image, valkey/valkey-bundle, with Valkey JSON, Valkey Bloom, Valkey Search and LDAP logins. We started valkey-bundle:9.1 once, outside our guides: it stored and read a JSON document, used a Bloom filter, and found a hash with a search index on a tag field. It has no time series, the image is twice the size at 287 MB, and our Valkey guide does not use it.

Updates

Both guides follow a minor-version tag, 9.1 and 8.10, and podman auto-update installs the patch releases. Redis maintains several minor versions at once: its images for 8.10.2 and for patch releases of 8.2 to 8.8 were all updated in October 2026. Valkey's 9.2 tag pointed at a release candidate when we tested, so a tag without a patch number is not always a stable release; the Valkey guide explains this.

Debian 13 ships both in its own repository, at older versions: Redis 8.0.2 and Valkey 8.1.1. Our guides use the projects' own images instead.

Licence and governance

We checked the projects' own pages and repositories on 14 October 2026.

• Redis is developed by Redis Ltd. Up to 7.2 it was under the BSD licence. In March 2024 the company moved Redis 7.4 to two licences that are not open source, the RSALv2 and the SSPLv1. Since Redis 8.0 you can choose the AGPLv3 instead, an open-source licence, and the bundled JSON, search, time series and Bloom modules are under the same three licences. Under the AGPLv3, if you change Redis's code and let others use it over a network, you must publish your changes; running it unchanged for your own apps asks nothing of you. Redis Ltd. also sells Redis Cloud and Redis Software, with features the open-source version does not have.
• Valkey was forked from Redis 7.2.4 in March 2024, after that licence change, and is under the BSD 3-clause licence, as are the modules in valkey-bundle. It is a project of the Linux Foundation, which owns the name. A technical steering committee of maintainers decides, and no more than a third of them may work for the same company; when we checked, its nine maintainers came from Amazon, Alibaba, Apple, Ericsson, Google, Oracle, Percona and Tencent. Valkey has no paid edition of its own; several cloud providers sell it as a managed service.

Both are free to run on your own server. In the traffic captures for our two guides, neither contacted any online service.

Which one to pick

Valkey suits most apps that use Redis as a cache, for sessions, queues or rate limits: it was as fast, used a little less memory for plain keys, wrote snapshots faster, and its licence and governance cannot be changed by one company. Its weak points: no JSON, search or time series in the official image, a second image for the modules, INFO answering as Redis 7.2.4, a Python client that lags redis-py slightly, and no way to load a snapshot from Redis 8. Follow the Valkey guide.

Redis suits you if your app uses JSON documents, search, time series or vector sets, or a framework that expects Redis 8 by name. Its weak points: a licence that has changed twice in two years, the AGPLv3 if you modify it, and a company that steers the project and sells the bigger version. Follow the Redis guide.

Both guides set a 4 GB memory limit and run comfortably on a VC-P Alloy, as on our test server; for a few hundred megabytes of cache, either needs very little. To switch later, your apps need only a new address and password; the data has to be copied key by key from Redis to Valkey, as its snapshots do not load.