Short answer: for a cache or a job queue, Valkey and Redis are the same thing in 2026. Same protocol, same commands, same clients, and on my bench the same speed – within a few percent, and the run-to-run noise was bigger than the gap. The real differences are the licence, the features Redis 8 added on top of the core, and one ugly migration trap: a single stream key written by Redis 8.10 stops Valkey from loading the snapshot or replicating from it.
So pick Valkey if you want a BSD-licensed server run by the Linux Foundation, or your cloud already defaults to it. Pick Redis if you use Redis Query Engine, Time Series, the probabilistic types beyond Bloom, or vector sets, or if you just don't want to think about a migration. If you are on Redis 8 today and want to move, read the migration section first.
What I tested
I did not want to write another comparison from release notes, so I ran both on my laptop (AMD Ryzen AI 7 PRO 450, 16 threads, Docker) with the official images:
-
redis:8.10.3– the latest Redis stable, released 26 October 2026 -
valkey/valkey:9.1.3– the latest Valkey stable, same day -
valkey/valkey-bundle– Valkey 9.1.3 plus the JSON, Bloom, Search and LDAP modules
Then I tried every way of moving data I could think of: copying the RDB snapshot, replication, and MIGRATE, with one key type at a time. Results are below. Everything here is as of 11 November 2026 – both projects ship a new minor every few months, so check the versions before you trust any of it.
Valkey vs Redis at a glance
| Redis 8.10 | Valkey 9.1 | |
|---|---|---|
| Licence | RSALv2, SSPLv1 or AGPLv3 (your pick) | BSD-3-Clause |
| Run by | Redis Ltd. | Linux Foundation, open governance |
| Forked from / based on | – | Redis OSS 7.2.4 |
| Wire protocol | RESP2 + RESP3 | RESP2 + RESP3 |
| Existing clients (redis-py, ioredis, go-redis, Jedis…) | Yes | Yes, with small gotchas (see below) |
| JSON | Built in | Module (valkey-json, in valkey-bundle) |
| Search / query engine | Built in (Redis Query Engine) | Module (valkey-search), smaller command set |
| Bloom filter | Built in | Module (valkey-bloom) |
| Cuckoo, Count-Min, Top-K, T-Digest | Built in | No |
| Time Series | Built in | No official module |
| Vector sets | Built in | No |
Hash field expiration (HEXPIRE) | Since 7.4 | Since 9.0 |
| Throughput, my bench, 4 I/O threads | ~650–700k ops/s | ~650–700k ops/s |
| Loads the other one's RDB | No | Only core types, and not streams from 8.10 |
Licences: how we got here
The short history, because it is the whole reason Valkey exists:
- 20 March 2024 – Redis moved from BSD to a dual RSALv2/SSPLv1 licence, starting with Redis 7.4 (Redis blog). Neither is an open-source licence by the OSI definition.
- 28 March 2024 – The Linux Foundation announced Valkey, a fork of Redis 7.2.4 under the old BSD licence, backed by AWS, Google Cloud, Oracle, Ericsson and Snap (LF press release).
- 1 May 2025 – Redis 8.0 added AGPLv3 as a third option (Redis blog). So Redis is open source again, but copyleft.
What this means in practice: if you run Redis as a cache behind your own app, AGPLv3 asks nothing of you. If you sell Redis as a service, or ship a modified Redis inside a product, you need a lawyer for Redis and you don't for Valkey. Most people reading this are in the first group.
Valkey vs Redis performance
Both projects publish big numbers. Valkey 8.0 claimed 1.19 million requests per second on a 16-core Graviton box (Valkey blog). Redis 8 claimed "up to 2x more operations per second" (Redis blog). Both numbers are real, and both are each project measured against its own older version, not against the other one.
My run: server pinned to 4 cores, the benchmark client on 8 other cores, persistence off, redis-benchmark -t set,get -n 1000000 -c 100 --threads 4 from the Redis image against both servers. Three runs each.
| SET ops/s | GET ops/s | |
|---|---|---|
Redis 8.10.3, io-threads 1 | 265–275k | 272–287k |
Valkey 9.1.3, io-threads 1 | 254–266k | 270–282k |
Redis 8.10.3, io-threads 4 | 615–670k | 676–706k |
Valkey 9.1.3, io-threads 4 | 500–700k* | 654–674k |
*The first Valkey run with 4 threads spent its first few seconds warming up; the other two landed at 658k and 701k.
That is a tie. Redis was a hair ahead on single-threaded SET, Valkey won one of the threaded SET runs, and the spread inside one server's three runs was bigger than the gap between servers. This is a laptop with tiny 3-byte values and no pipelining, so it tells you nothing about a 64-core box – but it does tell you that the "Valkey is 3x faster" headline is not something you will see on a small server.
Other people got the same mixed picture on bigger hardware:
- Momento, May 2025 – Valkey 8.1.1 at 999.8k SET/s vs Redis 8.0 at 729.4k on an 8-vCPU Graviton4 (Momento). Momento runs a Valkey-based service, keep that in mind.
- Lavik, October 2026 – Redis 8.10.2 at 976k GET/s vs Valkey 9.1.2 at 914k on a 16-vCPU Azure box (Lavik). Lavik sells its own key-value store, keep that in mind too.
One vendor finds Valkey ahead, another finds Redis ahead, and my laptop finds a draw. If speed is the only reason you are switching, don't.
What Redis has that Valkey doesn't
Redis 8 pulled the old Redis Stack modules into the core server: JSON, the Query Engine (FT.*), Time Series, five probabilistic types (Bloom, Cuckoo, Count-Min Sketch, Top-K, T-Digest), and vector sets. Pull redis:8 and they are all there.
Valkey keeps the core small and ships modules separately. The valkey/valkey-bundle image adds JSON, Bloom, Search and LDAP (Valkey docs). That covers JSON and Bloom. It does not cover Time Series, the other four probabilistic types, or vector sets, and valkey-search supports only part of the Redis Query Engine.
If your app uses any of those, the decision is made: stay on Redis.
What Valkey has that Redis doesn't
Mostly internals, not commands: a reworked I/O threading model (8.0), a new hash table that saves memory per key (8.1), numbered databases in cluster mode and Multipath TCP (9.0) (Valkey blog). Redis has caught up on some of it – it added its own I/O threading improvements in 8.4 and its own atomic slot migration. For a single-node cache you will not notice any of this.
Client libraries: mostly fine, three gotchas
redis-py, ioredis, node-redis, go-redis, Jedis and Lettuce all work against Valkey without code changes (Valkey migration guide). Valkey also has its own clients (GLIDE, valkey-py, valkey-go, iovalkey), but you don't need them to switch.
The gotchas, all real and all small:
- Valkey says it is Valkey. Since 8.0
HELLOanswersserver valkey, andINFOreportsredis_version:7.2.4forever, with the real version invalkey_version. I checked on 9.1.3: exactly that. Anything that gates onredis_versionthinks it is talking to Redis 7.2.CONFIG SET extended-redis-compatibility yesmakesHELLOsayserver redisagain – that also worked on 9.1.3. - redis-py client-side caching. redis-py 8.1.0 refused to enable client-side caching on Valkey 9.1.2 because of the server name (revisit.tech, October 2026).
- go-redis and
CLUSTER SHARDS. Valkey 9.1 adds a shardidfield, and go-redis 9.20.0 and older fail withunexpected key "id". Fixed in 9.20.1 (JusDB, November 2026).
If you don't use client-side caching or a cluster, you will probably hit none of them.
Migrating from Redis to Valkey: what actually works
This is the part I spent most of the time on, and the part where most comparison posts are too optimistic.
Valkey's own docs say it plainly: Redis 7.4 and later write data files Valkey cannot read (Valkey migration guide). Redis 8.10 writes RDB version 15. Valkey refuses it by default:
Can't handle RDB format version 15 Valkey 9 has an escape hatch, rdb-version-check relaxed, which tries to load newer Redis files anyway. Here is what happened with it, one key type at a time, Redis 8.10.3 to Valkey 9.1.3:
| Key type | RDB file copy | Replication |
|---|---|---|
| string, string with TTL, hash, list, set, sorted set | Loads | Works, live writes too |
| stream | Fails (opcode 27) | Fails – link stays down |
hash with field TTL (HEXPIRE) | Fails | – |
| JSON (on valkey-bundle) | Fails | – |
| Bloom (on valkey-bundle) | Fails | – |
| Time Series, vector set, search index | Fails | – |
The stream one is the trap. One stream key anywhere in the database and the whole load fails, and so does replication, because replication sends the same RDB format. Streams are not exotic: BullMQ uses them for job events, and plenty of apps use them as a small event log. Key-by-key MIGRATE did not help either – strings moved fine, the stream came back with ERR Bad data format.
For comparison, a snapshot from an earlier Redis 8 release loaded its stream into Valkey fine in the same test. So this depends on the exact Redis version you are leaving, which is one more reason to test with your own data and not trust a table, including mine.
The other direction is worse: Redis 8 cannot read a Valkey 9 snapshot at all (Wrong signature trying to load DB from file). Once you move to Valkey 9 and write data, going back means copying keys, not files.
How to migrate safely
- List your key types. Run
redis-cli --bigkeysor aSCANwithTYPEon a copy. If you seestream, a module type, or hashes with field TTLs, plan for them separately. - If you use JSON, Time Series, search or the probabilistic types, stop here. Either stay on Redis or rebuild those keys from your app.
- Test the load first. Copy last night's
dump.rdbinto a throwawayvalkey/valkey:9.1container with--rdb-version-check relaxedand check the log. If it starts andDBSIZEmatches, you are in the easy case. - Easy case: replicate. Start Valkey with
rdb-version-check relaxed, runREPLICAOF <redis-host> 6379, wait formaster_link_status:up, point the app at Valkey, thenREPLICAOF NO ONE. - Hard case: copy at the app level. Move core keys with replication or
MIGRATE, and recreate streams withXRANGEon the old server andXADDwith the same IDs on the new one. Or, for a cache, just start empty – a cache is supposed to survive that. - Check your client against the three gotchas above, especially if you use client-side caching or Redis Cluster.
If your Redis is a pure cache, step 6 is the only one that matters. Point the app at an empty Valkey and let it fill up.
Who runs which
The managed market has mostly moved to Valkey as the default:
- AWS ElastiCache prices Valkey 33% lower than Redis OSS on Serverless and 20% lower on nodes (AWS pricing).
- Render runs every new Key Value instance on Valkey 8 since February 2025 (Render changelog).
- Heroku Key-Value Store runs Valkey (Heroku changelog).
- DigitalOcean replaced its managed Redis with Managed Caching for Valkey in April 2025 (DigitalOcean).
- Azure went the other way: Azure Managed Redis is built with Redis Ltd.
- Arch Linux replaced
rediswithvalkeyin its main repository in April 2025 (Arch news), and Fedora has done the same since Fedora 41.
So if you pacman -S redis or create a "Redis" on Render today, you may already be running Valkey without knowing it. Check INFO server for server_name.
Valkey or Redis: which one to pick
- New project, plain cache, sessions or queues: either. Take whatever your platform or distro gives you. Valkey if you care about the licence.
- You use JSON, search, Time Series, vector sets or Cuckoo/Top-K: Redis.
- You sell a hosted service built on it, or ship it inside a product: Valkey, or talk to a lawyer about AGPLv3.
- You run Redis 7.2 or older: Valkey is a drop-in upgrade, its docs say so and the RDB format matches.
- You run Redis 8 and it works: there is no performance reason to move. If you move for the licence, follow the steps above and test with a real snapshot first.
FAQ
Is Valkey compatible with Redis?
Yes at the protocol and command level: Valkey is a fork of Redis 7.2.4 and existing Redis clients connect without code changes. No at the file level for newer Redis: Valkey cannot read RDB files from Redis 7.4 and later by default. Valkey 9 can try with rdb-version-check relaxed, which loads core types but fails on streams written by Redis 8.10, hash field TTLs and all Redis 8 module types.
Is Valkey faster than Redis?
Not in a way you will notice on a small server. On a 4-core test with Redis 8.10.3 and Valkey 9.1.3, both did about 650–700k GET and SET operations per second with 4 I/O threads, and the difference was smaller than the run-to-run noise. Published third-party benchmarks disagree with each other: some show Valkey ahead, some show Redis ahead.
Can I migrate from Redis 8 to Valkey with replication?
Sometimes. Valkey 9 can replicate from Redis 8.10 after CONFIG SET rdb-version-check relaxed, and strings, hashes, lists, sets and sorted sets sync, including live writes. A single stream key, a hash with field TTLs or any module type (JSON, Bloom, Time Series) makes the sync fail. Test with a copy of your real data first.
Can I go back from Valkey to Redis?
Not with files. Redis 8 rejects Valkey 9 RDB files with 'Wrong signature trying to load DB from file'. You need to copy keys at the application level or with a key-by-key tool.
Is Redis open source again?
Since Redis 8.0 (May 2025), Redis is available under AGPLv3 as one of three licence options, alongside RSALv2 and SSPLv1. AGPLv3 is an OSI-approved open-source licence. Valkey stays under the permissive BSD-3-Clause licence.
Does Valkey support JSON and search?
Through modules, not in the core server. The valkey-bundle image includes valkey-json, valkey-bloom, valkey-search and valkey-ldap. There is no official Time Series module, no vector sets, and valkey-search covers only part of the Redis Query Engine command set.
What are the main Redis alternatives in 2026?
Valkey is the main drop-in replacement: same protocol, BSD licence, Linux Foundation governance, and the default on AWS ElastiCache, Render, Heroku and DigitalOcean. Other options exist with their own trade-offs, but none is as close to Redis as Valkey.
If you'd rather not run any of this yourself, Hostim gives you EU-hosted apps with managed databases next to them, on a flat monthly price.
👉 Deploy an app on Hostim, free 5-day trial, no card
Last updated: November 2026.

