In March 2024, a Redis licensing change prompted a significant reorganization of its ecosystem. Days later, Valkey was announced: a new project based on Redis code, with a permissive licence and community governance. For businesses, agencies and development teams, the split raised a practical question: should they keep Redis, move to Valkey or choose a different data service?
The answer depends on what the application actually needs from its storage. Speeding up a website, maintaining a session, counting operations and coordinating a reservation are different requirements. Two services can both store key-value pairs while offering very different guarantees.
This analysis revisits the events of 2024, then distinguishes subsequent developments and the cloud options documented for this edition.
What is key-value storage?
Key-value storage works like a dictionary: a key identifies a value to retrieve. An application might associate catalogue:home:en with the catalogue summary displayed on its homepage. It knows which key to request; it does not necessarily need to search across several tables.
This model is particularly useful when the same information is requested frequently. Instead of recalculating a result for every visit, the application can keep a temporary copy. That is the principle behind a cache. The primary database remains the source of truth, while the cache avoids some repetitive work.
A TTL, or time to live, limits how long an entry remains usable. In Redis, the SET command can associate a value with a key and specify an expiration. The application must choose that duration: information that rarely changes and a stock level do not tolerate the same delay. The SET documentation describes these options.
Three questions matter more than the label “KV”:
- Freshness: how long can an old value remain visible?
- Coordination: what happens when several users change the same data at once?
- Recovery: can the data be rebuilt, or must it survive a failure?
A catalogue cache can be rebuilt. A paid order needs a system of record and recovery guarantees appropriate to the business.
Redis: a data structure server that goes beyond caching
Redis is often described as an in-memory cache, but its model is richer than a dictionary of text values. It provides strings, hashes, lists, sets, sorted sets and streams, among other structures. These can directly express application needs such as a counter, a leaderboard or an event history consumed by several processes. The exact features depend on the version and product in use. See the Redis data types and their comparison by use case.
For a team, the available operations matter as much as access speed. Reading a number, adding one and writing the result back in three separate requests can produce an incorrect result when two processes act at the same time. An appropriate server operation can avoid that race. An atomic command, a group of commands and a complete business transaction still need to be distinguished.
Network proximity also matters. Even a fast service can add noticeable latency to every exchange if it is far from the application. Round trips, value sizes and traffic peaks therefore belong in the assessment alongside the choice of engine.
What happened between Redis and Valkey in 2024?
Redis changes its licensing
On March 20, 2024, Redis announced that versions starting with Redis 7.4 would offer a choice of two licences, RSALv2 and SSPLv1, replacing the three-clause BSD licence for those new releases. The announcement framed the change as a response to the economics of Redis distribution, particularly in the cloud. That is the vendor’s position, rather than a judgment about every organization involved. Original Redis announcement
The change did not mean existing installations would stop working. Nor did it retroactively relicense versions already distributed under BSD. Redis subsequently clarified the position of earlier versions and service providers in its March 29, 2024 statement.
Valkey begins
On March 28, 2024, the Linux Foundation announced Valkey, based on Redis 7.2.4, with a three-clause BSD licence and community development. A fork here means a new development path starting from existing code. It was neither a completely rewritten engine nor simply a new commercial name for Redis. Linux Foundation announcement
March 28 was the project announcement. The first stable release, Valkey 7.2.5, was announced on April 16, 2024. That distinction matters when reconstructing the timeline. Valkey 7.2.5 announcement
Licensing, governance and commercial services are different questions
A licence defines the permissions and conditions for using code. Governance describes how a project makes decisions. A commercial service sets out what a provider operates, charges for and supports on behalf of its customer.
These dimensions can change independently. Open-source software can be sold as a managed service. Publicly readable code is not necessarily distributed under a recognized open-source licence. And choosing a permissive licence does not remove the work of operating the service properly.
For a business hosting or redistributing an engine, the practical starting point is to check the licence for the exact version and the intended way of providing it. A compliance decision should not rest solely on the name “Redis” or a blog summary.
What changed afterward: Redis 8 and Valkey’s continued development
On May 1, 2025, Redis added AGPLv3 as a third licensing option with Redis 8, alongside RSALv2 and SSPLv1. A current account that simply says Redis “left open source” without explaining this development would be incomplete. This was not a return to BSD, however: copyleft and permissive licences have different conditions. AGPLv3 option announcement
The official Redis licensing table distinguishes the generations of releases. The engine and its licences must also be considered separately from the contractual terms of a commercial service.
Valkey continued its own development: Valkey 8.0 was announced in September 2024, followed by Valkey 9.0 in October 2025. The projects share an origin, but their features and direction are not frozen at the point of the initial fork. Valkey 8.0, Valkey 9.0
Can Valkey replace Redis without changes?
In some environments, the transition is relatively straightforward. That does not justify a general promise of replacement with “no changes whatsoever.”
Valkey’s documentation describes compatibility with Redis OSS 7.2 and earlier versions, including the RESP protocol. It also states that data files produced by Redis CE 7.4 and later versions are not compatible with Valkey. A compatible client connection therefore does not prove that a backup, a module or every command from a newer release can be transferred. Official Valkey migration guide
Before choosing a migration method, examine the source version, the application’s client library, scripts, modules, cluster mode and data that must be preserved. A cache that can be cleared and rebuilt needs a different plan from a store holding sessions or pending work.
The same care applies to rollback. Once the target system has accepted new writes, simply returning to an older copy can lose those writes. The plan must explain how to handle that period, not just how to change a connection address.
Cloud options: replace the engine or change the architecture?
A managed service can reduce installation, update or monitoring work. It does not remove the need to check features, configuration, responsibilities and the limits of the chosen contract.
Services such as Amazon ElastiCache and Google Cloud Memorystore for Valkey offer Valkey in a managed environment. Redis Cloud also provides Redis as a managed service. The available engine, version, topology, regions and recovery mechanisms must be checked for the selected service; a product family’s name is not enough.
For a serverless application, a service such as Upstash also offers an HTTP/REST client for its Redis API-compatible service. This access method can be convenient in a Worker, but it does not establish support for every Redis command or behaviour. Its documented compatibility must be checked against the application’s actual usage.
Another option is to divide the requirements among specialized services. This is particularly relevant on a platform such as Cloudflare: KV, Durable Objects, D1, R2 and Queues are not different brands of the same engine. They serve different purposes.
| Main requirement | Service family to consider | First point to check |
|---|---|---|
| Keep an application that uses Redis commands | Managed or self-hosted Redis or Valkey | Compatibility of versions, commands and data |
| Cache simple results that can be rebuilt | Application cache, Memcached or HTTP cache, depending on the use case | Invalidation, expiration and rebuilding |
| Read frequently from several regions with few updates | Distributed KV storage | Acceptable propagation delay |
| Coordinate changes to the same business object | Coordination service or suitable transactional storage | Atomicity and the scope of guarantees |
| Query related, structured data | Relational database | Queries, transactions and data model |
| Store files or process work asynchronously | Object storage or message queue | Durability, retries and delivery semantics |
This table is a decision aid, not a statement that the products are technically interchangeable. Memcached, for example, focuses on caching simple values in memory; it does not automatically provide the structures and protocol a Redis application expects.
Cloudflare Workers KV: distributing reads while allowing for propagation
Workers KV stores values that can be cached across Cloudflare’s network. It is suited, among other uses, to frequent reads of data that changes infrequently. Its consistency is eventual: a change can take up to 60 seconds, or longer depending on caching, to become visible elsewhere. Even immediate visibility at the location of the write is not guaranteed. How Workers KV works
That trade-off can suit presentation settings or content where a short delay is acceptable. Our architectural conclusion would be different for an urgent access revocation, a unique reservation or a counter that must be exact: an old value could change the business outcome.
The FAQ also documents a per-key write limit for the Workers binding API. Limits of this kind, along with read caching, need to be checked before replacing a Redis workload that frequently changes the same key. Workers KV FAQ
Workers KV is not a Redis server implementing Redis commands. Adapting an application to its API is an architectural change that requires its own tests. Storing keys and values does not guarantee the same protocol or atomic operations. The Workers KV API overview illustrates this difference in interfaces.
The other Cloudflare building blocks and their roles
Durable Objects: coordinating a specific state
A Durable Object associates an identity, code and storage with a logical object. Its storage offers strong consistency within its scope. This makes it possible to organize decisions around one entity, such as a collaborative room or a shared counter. It does not automatically provide a global transaction across every object in an application. State held only in memory must be saved to persistent storage to survive a restart. Introduction to Durable Objects
One design approach is to send operations concerning the same resource to the object responsible for it. The developer must still define the rules, handle errors and check load limits. Putting every operation in a business into one object would concentrate responsibilities in a way that needs to be assessed.
D1: keeping a relational model
D1 provides a managed SQL database built on SQLite. This is a relevant service family when an application needs tables and structured queries rather than simple key-based access. For read replication, the documentation specifies the Sessions API and sequential consistency within a session; this should not be summarized as a blanket guarantee of strong global consistency. D1 does not expose the Redis protocol. D1 documentation, read replication
R2: storing objects and files
R2 is object storage: images, documents, exports and other content identified by a key. That use of the word “key” does not make it a Redis cache or a coordination service. An application might, for example, keep an export in R2 and its metadata in a database suited to searching. R2 architecture
Cache API and Queues: two further, distinct requirements
The Cache API works with cached HTTP responses. Its contents are local to the data centre processing the operation; they should not be treated as durable global state. Cache API
Queues decouples the production and processing of messages. Its at-least-once delivery means consumers must be designed to receive a message again without repeating an unwanted effect. A message queue alone does not replace session storage or a Redis leaderboard. Queues delivery guarantees
Four practical situations to guide the choice
An existing website uses Redis as an object cache. Start by confirming that its plugin or framework supports Valkey, then measure actual access patterns. An engine migration may be more proportionate than rewriting the integration for a KV API. Check what happens when the cache is empty: the primary system must be able to handle rebuilding it.
A distributed application serves settings that rarely change. Distributed KV can simplify delivery if an older version remains acceptable during propagation. Plan for configuration versions and fallback behaviour. A security rule that must take effect immediately deserves a different analysis.
Several users try to reserve the same resource. First identify where the decision is made authoritatively and atomically. A cache can speed up the display of availability, but it should not accidentally become the arbiter of a one-off sale when its consistency cannot support that guarantee.
An application generates documents in the background. A queue can distribute work, object storage can retain the files, and a database can record their status. This separation can be clearer than assigning every responsibility to a single engine. It also adds integrations to monitor: each additional service should have a reason to exist.
Performance, persistence and availability: avoiding shortcuts
“In memory” does not necessarily mean “without durable storage.” Valkey supports RDB snapshots and an AOF log, with configuration choices and trade-offs. Having these mechanisms does not establish that a backup and recovery policy has been defined or tested. Valkey persistence
A Valkey transaction groups commands without other clients’ commands interleaving during execution, but it does not automatically roll back commands that have already run. The word “transaction” therefore should not be taken to mean full equivalence with SQL database behaviour. Valkey transactions
Replication is not a universal guarantee of zero data loss either. The documentation explains that acknowledged writes can still be lost during failover, depending on configuration. Valkey replication
Memory limits and eviction policies also influence which data the engine may remove or which writes it may reject. A policy suited to a rebuildable cache can be inappropriate for essential business state. Eviction management
When comparing options, measure application response times, particularly slow requests, errors, cache hit rates, evictions and the load on the system of record. Include network costs, backups, replicas and operational effort. An instance price or an advertised latency figure alone does not describe the real cost of a usable service.
Security: clarify who protects what
A data engine should not be exposed directly to the Internet without an appropriate architecture and controls. Valkey’s documentation includes network restrictions, access controls and TLS. These mechanisms must be configured and verified; their presence in a product does not mean they are active in a particular environment. Valkey security
For a managed service, establish who controls accounts, connection secrets, permissions, backups and alerts. Also check processing locations and the provider’s terms when data is subject to residency requirements. A service accessible from several countries does not, by itself, guarantee storage in a particular region.
A controlled approach to migration
- Inventory the dependencies. Identify applications, versions, clients, commands, scripts and features that depend on the engine. Distinguish rebuildable caches from data that must be preserved.
- Set the business criteria. Define acceptable staleness, tolerable downtime and maximum acceptable data loss. Establish who approves those criteria.
- Choose a specific target. Examine licensing, compatibility, networking, region, limits and the division of responsibilities. Avoid a decision based solely on a brand.
- Test a representative environment. Check expiration, concurrency, reconnections, errors and load growth using appropriate test data.
- Prepare recovery. Test restoration where required and establish how new writes will be handled during cutover and any rollback.
- Cut over against observable criteria. Check user journeys and relevant data, not just whether a network port responds. Plan a stop decision if the criteria are not met.
- Stabilize and document. Compare measurements, verify access and alerts, then retire the previous environment only after validation and according to the agreed retention requirements.
This approach follows the same reasoning as planning database changes around the applications a business uses. A successful migration is judged by how the service works and how it can recover, not simply by the presence of a new engine.
What is the right decision for your business?
Valkey is an option to consider when retaining an ecosystem close to Redis OSS with a permissive licence. Redis remains an option to assess against its version, features and licence. Specialized cloud services enable other architectures, provided their APIs and particular guarantees fit the requirements.
The starting point should be your application: what it stores, the operations it performs, the consequences of stale data and the skills available to operate it. A small business, an agency managing several websites and a transactional platform do not necessarily need the same combination.
Explore our approach to cloud and infrastructure services or discuss your environment with Nuagerie. The aim is a proportionate solution and a verifiable transition, with clearly defined responsibilities and limits.