# Valkey vs Redis in 2026: What Is Different and What Breaks When You Switch

> Source: <https://dev.to/pavel-hostim/valkey-vs-redis-in-2026-what-is-different-and-what-breaks-when-you-switch-75i>
> Published: 2026-11-11 12:44:54+00:00

**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 <redis-host> 6379`, wait for `master_link_status:up`, point the app at Valkey, then `REPLICAOF NO ONE`.` MIGRATE`, and recreate streams with `XRANGE` on the old server and `XADD` with the same IDs on the new one. Or, for a cache, just start empty – a cache is supposed to survive that.
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.

The managed market has mostly moved to Valkey as the default:

`redis` with `valkey` in its main repository in April 2025 (
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`.

**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](https://hostim.dev) 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.*