Valkey vs Redis in 2026: What Is Different and What Breaks When You Switch A developer benchmarked Redis 8.10.3 against Valkey 9.1.3 on a 16-thread AMD machine in Docker and found the two in-memory data stores effectively tied on throughput, at roughly 650–700k ops/s with four I/O threads and within a few percent single-threaded. The comparison found the substantive differences are licensing (Redis's RSALv2/SSPLv1/AGPLv3 versus Valkey's BSD-3-Clause under Linux Foundation governance), Redis 8's built-in modules for search, time series, probabilistic types and vector sets, and a migration trap: a stream key written by Redis 8.10 prevents Valkey from loading the RDB snapshot or replicating from it. 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. 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. | | 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 | The short history, because it is the whole reason Valkey exists: 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. Both projects publish big numbers. Valkey 8.0 claimed 1.19 million requests per second on a 16-core Graviton box Valkey blog https://valkey.io/blog/unlock-one-million-rps/ . Redis 8 claimed "up to 2x more operations per second" Redis blog https://redis.io/blog/redis-8-ga/ . 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: 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. 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 https://valkey.io/topics/valkey-bundle/ . 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. 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 https://valkey.io/blog/introducing-valkey-9/ . 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. redis-py, ioredis, node-redis, go-redis, Jedis and Lettuce all work against Valkey without code changes Valkey migration guide https://valkey.io/topics/migration/ . 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: HELLO answers server valkey , and INFO reports redis version:7.2.4 forever, with the real version in valkey version . I checked on 9.1.3: exactly that. Anything that gates on redis version thinks it is talking to Redis 7.2. CONFIG SET extended-redis-compatibility yes makes server redis again – that also worked on 9.1.3. CLUSTER SHARDS . id field, and go-redis 9.20.0 and older fail with unexpected key "id" . Fixed in 9.20.1 If you don't use client-side caching or a cluster, you will probably hit none of them. 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 https://valkey.io/topics/migration/ . 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. redis-cli --bigkeys or a SCAN with TYPE on a copy. If you see stream , a module type, or hashes with field TTLs, plan for them separately. dump.rdb into a throwaway valkey/valkey:9.1 container with --rdb-version-check relaxed and check the log. If it starts and DBSIZE matches, you are in the easy case. rdb-version-check relaxed , run REPLICAOF