Valkey continues the Redis codebase under foundation governance

The code available for a database and the organization directing its next release are different dependencies. On March 28, the Linux Foundation announced its intent to form Valkey, continuing development from Redis 7.2.4 under the BSD 3-clause license. Former Redis contributors have assembled technical leadership, with support from companies including AWS and Google Cloud. The announcement establishes an independent development path for an existing engine.

This follows Redis's March 20 licensing announcement, which places future releases under a choice of RSALv2 or SSPLv1 instead of BSD, starting with Redis 7.4. Redis presents the change as a way to fund development while changing the terms for competing service providers. Valkey's announced direction retains the earlier permissive license and adds foundation-based governance.

I have used Redis since its release, so the underlying data model is familiar territory. My preference is to retain an open development path for infrastructure that becomes a long-term dependency. That preference does not establish the quality of any future release. It establishes why the governance and distribution terms belong in the engineering decision alongside the implementation.

The starting point is an existing server

The announced baseline matters because Valkey begins with a specific implementation rather than a fresh protocol-compatible rewrite. The Redis 7.2.4 README describes a server that exposes mutable data structures through commands over TCP sockets. Multiple processes can access those shared structures through a common server. That is the existing application model from which the new project starts.

The same document describes replication and clustering, together with configurable persistence and durability. Those are substantial implementation commitments. Continuing the code means inheriting their behaviour and maintenance obligations. The governance change does not replace them with a different consistency model or make their operational tradeoffs disappear.

A simple command sequence illustrates the application boundary. The protocol exposes an operation on a named value, and the server owns the representation behind that value.

SET example:counter 0
INCR example:counter
GET example:counter

The starting implementation supports richer structures as well as strings. Its object representation carries a type and an encoding, so the internal representation can vary while the command-level abstraction remains recognizable. That distinction is important when evaluating future engine work. Improvements to an internal encoding need not require the application to adopt another data model.

It also explains why familiarity with Redis is relevant without proving complete future compatibility. The baseline defines what exists now. Changes made afterward will need to maintain or deliberately revise particular behaviours. An engineering assessment should attach compatibility claims to versions and interfaces, rather than treating a shared starting point as a permanent guarantee.

Persistence remains an implementation concern

The inherited architecture includes RDB snapshots and append-only persistence. Its version-pinned README explains that the server uses a child process to write a memory snapshot and to perform append-only-file rewriting. Parent and child initially share memory through the operating system's fork behaviour. This is part of the engine being continued, not a new mechanism introduced by the announcement.

The document also distinguishes recording commands in an append-only file from rewriting that file. Command execution can append the operations needed for persistence, while rewriting constructs another representation of the current state. A project taking responsibility for the server inherits both paths and their interactions with runtime state.

Those details matter because replacing a distribution name in an inventory is not the whole operational dependency. Backup procedures and recovery expectations concern the files the engine writes and the state it reconstructs. The shared baseline provides a concrete implementation to inspect for those questions. Foundation governance does not itself certify that every existing procedure is correct.

The same is true of deployment packaging. The README separates installing binaries from arranging configuration and service startup. A compiled executable can exist without the operating system knowing how to start it at boot or where to obtain its configuration. A new project's release process will need to make those deployment inputs clear, even when the engine's command protocol remains familiar.

I regard that inherited work as a reason to value a continuation by experienced contributors. The hard part is maintaining the server's existing behaviours while deciding what to improve. A project announcement can provide a place to do that work, but the actual release artifacts and their behaviour remain the evidence users will consume.

Event-loop work still shapes execution

The Redis baseline's source overview identifies the main event loop and its periodic tasks. It distinguishes receiving client bytes, parsing commands and dispatching the command implementation. Output accumulates in buffers and is written when the connection can accept it. The command interface therefore rests on a series of internal stages with different costs.

The README also explains that the global server state includes database data, the command table and connected clients. This is useful context for understanding why performance work needs to preserve execution assumptions. Moving work between threads or changing buffering affects code that shares these structures. It cannot be evaluated solely by counting new worker threads.

The command table itself is generated from command metadata, according to the baseline's source overview. That metadata includes how commands are described and dispatched. A continuing project inherits a structured place to maintain those definitions, which matters when applications and tools inspect command capabilities. Compatibility includes what a client can learn about the server as well as what happens when it submits an ordinary data operation.

Client state includes a query buffer and parsed arguments, together with reply storage. These structures connect the wire protocol to command execution. Changing an internal representation does not remove the need to preserve the result a client observes. This provides a concrete way to separate engine improvements from application-visible changes during independent development.

The source distribution also includes its tests and dependency sources. The README describes the tests as Tcl-based and lists libraries included under the dependency directory. Those are additional inherited maintenance responsibilities. A working fork needs to keep the build and test environment meaningful as code changes, alongside preserving the server behaviour applications already depend on.

That is an architectural observation about the inherited source, not a claim that Valkey has already implemented a new execution design. The announcement lists intended development work, but a roadmap item and released functionality are different evidence. The practical starting point remains the server architecture documented in the chosen baseline.

The baseline also includes configurable allocator selection and build options for TLS. These show that one code version can produce artifacts with different supporting dependencies. A reproducible deployment needs to identify the built artifact and its options as well as the repository revision. That requirement continues across a fork because the operating environment still consumes executable code.

Distribution permission and project direction are separate

The Redis 7.2.4 license file permits redistribution and modification subject to its conditions. It requires preserving notices and includes a restriction on using contributor names for endorsement without permission. This provides the distribution basis for the existing code. It does not require users to follow only one organization's future release line.

The new project adds another decision about who maintains that code and reviews its changes. That decision is organizational, while the inherited license describes permissions for the baseline. Keeping them separate makes the announcement easier to assess. Having permission to continue code does not automatically supply maintainers, release engineering or an effective review process.

Conversely, an active maintenance organization does not make distribution terms irrelevant. Infrastructure can be embedded in products and operated through several providers over its lifetime. A permissive continuation is attractive to me because it keeps those choices open at the code-distribution level. The quality of a particular provider or release still requires its own evidence.

The announcement also names existing contributors and technical leadership. Its significance is that the independent path has people willing to maintain it, rather than consisting only of a copied repository. A continuing project needs decisions about defects and release scope. Those decisions will shape whether applications can keep relying on the familiar command and persistence behaviour.

At this point, the useful engineering conclusion is limited and concrete. There is an announced foundation-based continuation of the BSD-licensed Redis 7.2.4 code. Its inherited architecture supplies a well-defined starting point for persistence, command execution and deployment. Subsequent releases will provide the evidence for how that independent maintenance develops.