Valkey vs Redis: the licence change, the fork and compatibility

Valkey is the open-source fork of Redis, created under the Linux Foundation in March 2024 from Redis 7.2.4 after Redis changed its licence. For an application, the two are the same thing: the same protocol, the same commands, the same configuration directives, the same default port 6379, and the same client libraries - your Redis client connects to Valkey without a code change. They have drifted apart since the fork in features added after 7.2, and in licensing, which is the reason the fork exists. If you use Redis as a cache, session store, queue or rate limiter, you can switch to Valkey without noticing. If you depend on something added to Redis after 7.2, such as the modules folded into Redis 8, check before you move.

What happened: the licence change#

Redis was released under the three-clause BSD licence from 2009, and for most of its life that was the end of the story. In 2018 Redis Ltd moved some of its add-on modules to more restrictive licences, while the core stayed BSD. In March 2024 the core changed too.

The two 2024 licences - the Redis Source Available License v2 and the Server Side Public License v1 - are not approved open-source licences. In practice they restrict offering Redis as a managed service in competition with Redis Ltd, which is exactly what the large cloud providers were doing. Valkey was the response: the maintainers who had been working on Redis at those companies forked the last BSD release, and Amazon Web Services, Google Cloud, Oracle, Ericsson and Snap were among the first backers.

The 2025 addition of AGPLv3 makes Redis 8 open source again by the usual definition. AGPL is a copyleft licence with a network clause: if you modify Redis itself and let users interact with it over a network, you must offer them your modified source. For people who use Redis unmodified as a component, that changes very little, but many companies have blanket policies against AGPL code, and the fork had a year's head start by then.

What the licences mean for the people actually using the software:

• Running it behind your own application - a cache, a session store, a queue - has been permitted under every licence Redis has used, including RSALv2 and SSPLv1. Nobody is asking you to pay for connecting to Redis.
• Modifying the server and running the modified version is where AGPLv3 asks you to publish your changes to the users of that service. Using it unmodified asks nothing of you.
• Selling Redis itself as a service is what RSALv2 and SSPLv1 were written to prevent, and why the providers who do that moved to Valkey.
• Redistributing it in a Linux distribution or a product is simplest under BSD, which is why distributions favoured the fork.

For a developer running one instance behind an application, then, none of this licensing affects what you are allowed to do. It matters to companies building hosted services, and to Linux distributions deciding what to ship. Fedora, for example, replaced its Redis package with Valkey.

What Valkey is#

Valkey is a Linux Foundation project with an open governance model, a technical steering committee drawn from several companies, and a BSD-3-Clause licence that cannot be changed by one vendor. Its binaries are called valkey-server, valkey-cli, valkey-benchmark, valkey-check-aof and valkey-check-rdb, its configuration file is valkey.conf, and most packages also install compatibility names so that scripts calling redis-cli keep working.

The project has not stood still. The headline changes since the fork:

• 8.0 reworked I/O threading so a single instance can use several cores for network handling, added dual-channel replication, and added per-slot metrics in cluster mode.
• 8.1 replaced the core dictionary with a more cache- and memory-efficient hash table, cutting per-key overhead.
• 9.0 added per-field expiry on hashes (HEXPIRE, HTTL and friends), atomic slot migration in cluster mode, and numbered databases in cluster mode.

Modules for JSON, Bloom filters and search exist as separate Valkey projects (valkey-json, valkey-bloom, valkey-search), distributed alongside the server in a bundle rather than built in.

What Redis is now#

Redis 8 merged what used to be Redis Stack - JSON documents, the query and search engine, time series and probabilistic structures such as Bloom filters - into the main distribution, and added a vector set data type. If you use any of those, they are part of the core in Redis 8 and are not in a default Valkey server.

Redis 7.4 also introduced hash field expiration, which Valkey added in 9.0, and Redis 8 added commands around it. Both projects continue to add commands, and the overlap past 7.2 is partial: some features have arrived in both under the same names, some exist only in one. For anything newer than 7.2, check the command's documentation page for the specific server you run, rather than assuming.

Compatibility in practice#

What is identical, and will stay identical because both projects treat it as a contract:

• The protocol. RESP2 and RESP3, the same framing, the same HELLO negotiation.
• Every command that existed in Redis 7.2 - strings, hashes, lists, sets, sorted sets, streams, pub/sub, transactions with MULTI and EXEC, Lua scripting with EVAL, functions with FCALL, ACL, CLIENT, CONFIG, INFO.
• Configuration. valkey.conf accepts the same directives as redis.conf - maxmemory, maxmemory-policy, appendonly, save, requirepass and the rest.
• Persistence files. Valkey reads RDB snapshots and append-only files written by Redis 7.2 and earlier.

One deliberate detail helps old clients: Valkey's INFO server output still includes redis_version:7.2.4, alongside server_name:valkey and valkey_version with its real version. Client libraries that check the server version before using a feature see the number they understand.

$ valkey-cli -h db.example.net -p 6379 --askpass INFO server | grep -E 'version|server_name'redis_version:7.2.4server_name:valkeyvalkey_version:8.1.1

Where you need care is data written by Redis 7.4 and later. Their snapshot format may be newer than a given Valkey release reads, so check the Valkey release notes before loading a Redis 7.4+ dump file, or move the data at the command level as described below.

Clients and libraries#

The client libraries were never relicensed - they are separate projects, mostly MIT-licensed - and they all speak to Valkey unchanged.

Valkey GLIDE is the project's own client, with a shared core written in Rust and bindings for several languages. It is a good choice for a new project and an unnecessary change for an existing one. Frameworks that sit on top of these - Sidekiq, BullMQ, Celery, Django's cache backend, Laravel's Redis driver, Spring Data Redis - work through the underlying client and do not care which server answers.

The connection URL is the same too: redis://:password@host:port/0, or rediss:// for TLS. Some Valkey-branded clients also accept valkey://, but the redis:// form works everywhere and is what configuration files expect. Valkey getting started covers connecting and the first commands.

Moving from Redis to Valkey#

How you move depends on what the data is.

A cache. Do not migrate it. Point the application at the new server and let it fill. The first minutes run with a cold cache, so do it outside peak hours, and if a cold cache would overload your database, read the stampede section of Valkey caching patterns first.

Sessions and queues. Usually short-lived enough to drain rather than copy: stop enqueueing on the old server, let workers finish, switch, and accept that users with a session on the old server log in once more.

Data you must keep. From Redis 7.2 or earlier, a replica is the cleanest path - start Valkey, run REPLICAOF old-host 6379 (with masterauth set if the source has a password), wait for the sync to finish, then promote it with REPLICAOF NO ONE and repoint the application. Where the new server cannot reach the old one, copy key by key with SCAN, DUMP and RESTORE, which preserves types and TTLs:

import redissrc = redis.Redis(host="old-host", port=6379, password="old-pass")dst = redis.Redis(host="new-host", port=6379, password="new-pass")for key in src.scan_iter(count=1000):    payload = src.dump(key)    if payload is None:        continue                        # expired between SCAN and DUMP    ttl = src.pttl(key)    dst.restore(key, ttl if ttl > 0 else 0, payload, replace=True)

DUMP produces a payload in the serialisation format of the source version, so this works from Redis 7.2 and earlier. From Redis 7.4 or 8, use a tool that reads values with ordinary commands and writes them again, or have the application rebuild what it needs.

Before switching, run INFO server and MODULE LIST on the old server. A module in that list - ReJSON, search, timeseries - is a dependency to resolve first.

Performance: what actually differs#

Benchmarks comparing the two are mostly published by people with a stake in the result, and most measure a large machine pushed to millions of requests a second. A few differences are real, and it helps to know which ones matter at the size most applications run.

Command execution is single-threaded in both. Each command runs to completion before the next starts, which is what makes INCR atomic and Lua scripts safe without locks. Neither project has changed that, and neither will, because the whole programming model depends on it. What both can spread across threads is the network work around commands: reading requests from sockets, parsing them, and writing replies. Redis added threaded I/O in version 6; Valkey 8 reworked it substantially, so that a single Valkey instance on several cores handles far more connections and requests before the main thread becomes the limit. It is controlled by the io-threads directive in both, and it only helps when there are spare cores and a lot of concurrent clients.

Memory per key fell in Valkey 8.1. The new hash table stores keys with less overhead. A dataset of a few large values will not notice; a dataset of millions of small keys - session IDs, rate-limit counters, cache entries of a few dozen bytes - fits measurably more into the same memory. On a small instance, where memory is the limit you actually hit, that is the improvement worth caring about.

Round trips dominate at small scale. For an application sending a few hundred commands a second, the server's internal speed is irrelevant: each command costs a network round trip, and that is where the time goes. Pipelining several commands in one round trip, using MGET instead of a loop of GET, and keeping connections open in a pool all do more for your latency than any choice between the two servers. valkey-benchmark (or redis-benchmark, which works against either) measures what your own server and network deliver, which is the only benchmark that applies to you:

$ valkey-benchmark -h db.example.net -p 6379 -a "$PASS" -t set,get -n 100000 -q$ valkey-benchmark -h db.example.net -p 6379 -a "$PASS" -t set,get -n 100000 -P 16 -q

The second line pipelines sixteen commands per round trip. The difference between the two results is usually the most persuasive argument for pipelining you will ever see.

Which one to choose#

For most applications it does not matter, and the deciding factor is what your platform offers. Choose Valkey when you want a BSD-licensed server with multi-vendor governance, or when it is what your distribution or host provides. Choose Redis 8 when you need its built-in JSON, search, time series or vector features in one server and the AGPL suits you. Either way, write application code against the Redis 7.2 command set where you can, and it will run on both for years.

The more important question is usually not which one, but whether you need either - Redis: when you need it makes that case - and how much memory and persistence the job needs.

Valkey on RE:NODE#

The database line includes Valkey, not Redis, and it is called that on purpose. It speaks the Redis protocol, so any Redis client or library connects to it unchanged. Each server is password-protected, with credentials generated for it, and reached on the host and port shown for the plan; there is no proxy slot, so the application connects directly. Data is saved to disk with both AOF and snapshots, so a restart does not empty it. Plans start at 256 MB of memory and go up to 4 GB. Which database should I use places it beside the PostgreSQL, MySQL, MongoDB and SQL Server lines.

FAQ#

Is Valkey a drop-in replacement for Redis?

For Redis 7.2 and earlier, yes: same protocol, commands, configuration and file formats. Applications that use features added in Redis 7.4 or 8 - the merged JSON, search and time series modules, for instance - need checking command by command before switching.

Do I need to change my Redis client library?

No. redis-py, ioredis, node-redis, Jedis, Lettuce, go-redis, StackExchange.Redis and phpredis all connect to Valkey as they are. Valkey-branded forks and the GLIDE client exist, but switching to them is optional.

Is Redis open source again?

Since Redis 8 in 2025, Redis can be used under AGPLv3, which is an OSI-approved open-source licence, as an alternative to RSALv2 and SSPLv1. Redis 7.4 was released only under the two source-available licences. Valkey has stayed on BSD-3-Clause throughout.

Why does Valkey report redis_version 7.2.4?

For compatibility. Some client libraries check the server's version before using a feature, and they know Redis version numbers. Valkey keeps reporting the version it forked from in that field, and reports its own version separately as valkey_version.

Can Valkey read my Redis dump.rdb file?

Files written by Redis 7.2 and earlier, yes. Files from Redis 7.4 or later may use a newer format; check the Valkey release notes for your version, or migrate at the command level instead of copying the file.