Valkey vs Redis in 2026: comparison and migration guide

In March 2024, Redis Ltd. switched to the BSL (Business Source License), excluded from OSI open source definitions. The reaction was immediate: the Linux Foundation coordinated the creation of Valkey with support from Meta, Google, AWS and several major hosting providers. The fork started from Redis 7.2 code under the BSD licence. In May 2025, Redis returned to an OSI-compatible licence by adopting AGPLv3 — a positive signal, but AGPLv3 is strong copyleft: any software that embeds it must publish its source code, creating real constraints for reseller hosting providers and commercial software vendors. Meanwhile, Valkey 9.1 became the default package on Ubuntu 24.04+, Debian 13 and Fedora 40+, consolidating adoption across major distributions.

The most common question before a migration is about the protocol. Valkey implements 100% of the Redis Serialization Protocol in both versions.

RESP2 (the historic protocol) is fully supported. All your existing client libraries — ioredis, Predis, redis-py, Jedis, StackExchange.Redis — communicate with Valkey without any code or configuration changes. The replacement is transparent at the socket level.

RESP3 (introduced with Redis 6.0) is also supported by Valkey 9.1. This protocol brings enriched response types — maps, sets, doubles, booleans, attributes — allowing modern clients to reduce parsing round-trips. Libraries that enable RESP3 by default (ioredis 5+, redis-py 5+) work without modification with Valkey.

One point to verify: if your client negotiates the protocol via the HELLO command, Valkey responds identically to Redis. The HELLO 3 command activates RESP3 on both systems the same way. You can confirm this on an existing Valkey instance with valkey-cli HELLO 3.

The persistence file format is the other critical point of a migration. Valkey reads and writes the same formats as Redis, without intermediate conversion.

RDB (Redis Database Backup): Valkey supports RDB versions 6, 7, 8, 9 and 10. A dump.rdb file exported from Redis 7.x or 8.x imports directly into Valkey 9.1 by placing it in Valkey's dir directory before startup. No conversion tool is needed.

AOF (Append-Only File): the AOF journal format is identical between Redis and Valkey. If you use AOF persistence or mixed mode (aof-use-rdb-preamble yes), your existing files are read by Valkey without modification. The BGSAVE and BGREWRITEAOF commands behave the same way.

In-memory data format: Valkey data structures — strings, hashes, lists, sets, sorted sets, streams, HyperLogLog, bitmaps, geospatial — are identical to Redis. Internal encodings (ziplist, listpack, skiplist, quicklist, intset) have been maintained at parity. A client that stores a hash in Redis retrieves it intact from Valkey.

The full Redis command set is supported by Valkey. The main categories — strings, hashes, lists, sets, sorted sets, streams, pub/sub, transactions, Lua scripting, keyspace notifications, cluster — work identically.

Lua scripting: Valkey supports EVAL, EVALSHA and SCRIPT LOAD. Lua scripts written for Redis run without modification on Valkey. The cjson library and redis.call() functions are available, with one nuance: Valkey has introduced compatibility with the valkey.call() alias for new scripts, but redis.call() remains functional for backwards compatibility.

Cluster: the Gossip protocol and cluster management commands (CLUSTER INFO, CLUSTER NODES, CLUSTER MEET, CLUSTER FAILOVER) are identical. A Valkey node can participate in an existing Redis cluster — however, a mixed Redis/Valkey cluster is not recommended in production: major versions may introduce behavioural differences on internal commands. Migrating nodes one by one remains the safe path.

ACL (Access Control Lists): the ACL rule format is identical. An aclfile exported from Redis (ACL SAVE) can be reloaded into Valkey. The ACL LIST, ACL SETUSER, ACL GETUSER commands work identically.

Keyspace notifications: the notify-keyspace-events configuration and subscription patterns (__keyevent@*__:set, etc.) are identical. Your pub/sub consumers listening to keyspace events do not need to be modified.

What differs: the proprietary Redis Stack modules — RedisJSON, RediSearch, RedisTimeSeries, RedisBloom — are not available in Valkey. Open source alternatives exist, but the API is not guaranteed to be identical. If your code calls commands like JSON.SET, FT.SEARCH or TS.ADD, direct migration is not yet possible.

The valkey.conf syntax is identical to redis.conf. You can copy your existing configuration file without rewriting. A few points require specific attention.

Default paths: Valkey uses /etc/valkey/valkey.conf and /var/lib/valkey/ instead of /etc/redis/ and /var/lib/redis/. If you copy your configuration, update the dir, logfile, pidfile and aclfile directives to point to Valkey paths.

systemd service name: the service is called valkey (not redis-server). Commands are therefore systemctl start valkey, systemctl enable valkey.

TLS: Valkey supports TLS on client connections (tls-port, tls-cert-file, tls-key-file, tls-ca-cert-file) identically to Redis 6+. If you have enabled TLS in Redis, the same configuration works in Valkey without modifying your clients.

maxmemory and eviction: eviction policies (allkeys-lru, volatile-lru, allkeys-lfu, noeviction, etc.) are identical. Your current policy transfers directly.

Bind and protection-mode: Valkey starts in protected mode by default (like Redis), refusing non-loopback connections if no password is defined. Your bind and requirepass (or ACL) configuration transposes directly.

This is one of Valkey's strengths: no client library requires modification to connect to Valkey. Since the protocol is identical, the client does not know whether it is talking to Redis or Valkey.

JavaScript / Node.js: ioredis, node-redis (the redis npm package), redis — all work. Change only the host and port in your connection configuration.

Python: redis-py (the redis package on PyPI), aioredis — compatible. The connection Redis(host='valkey-host', port=6379) works without any other change.

PHP: phpredis (C extension), Predis (pure PHP) — compatible. No code changes.

Java: Jedis, Lettuce, Redisson — compatible. Adapt only the connection parameters.

.NET: StackExchange.Redis — compatible. Same connection string, host and port updated.

Go: go-redis, rueidis — compatible.

If you use an abstraction like Laravel Cache (CACHE_DRIVER=redis), Django django-redis, Spring Data Redis or Symfony Cache with the Redis adapter, these abstraction layers reconnect to Valkey without code changes — only the connection DSN changes.

Valkey is the natural choice in several contexts. Hosting providers and resellers are the most affected: Redis's AGPLv3 requires publishing the code of any service that embeds it, a constraint incompatible with most commercial offerings. New projects have no reason to start on Redis: Valkey is the default package on recent distributions, performance is superior and the licence has no restrictions. GDPR and sovereignty stacks also benefit from the Linux Foundation governance, which is more neutral than a private vendor. Finally, if you do not use the proprietary Redis Stack modules (RedisJSON, RediSearch, RedisTimeSeries), migration is transparent — all your existing libraries and configurations remain valid.

Valkey is just one piece of your data stack. If you also host a relational database, see our guide on MariaDB on VPS: configuration, performance and replication. For full-text search, our Elasticsearch on VPS guide covers installation, memory tuning and production indexes. Each component deserves configuration adapted to your workload — our Cloud VPS gives you full control of your environment.