Redis 7.0 RC1 changes the unit of persistence

Redis 7.0 RC1 changes what it means to preserve the files behind a running Redis instance. Append-only persistence becomes a set of files with a manifest, and Functions introduce named server-side libraries. The database's operational artifacts now include more structure than a single append-only filename and application-managed script text.

The January 31 release notes describe RC1 as an early version for community testing and explicitly exclude production suitability. They also identify compatibility changes before listing features. Redis writes RDB version 10, uses multipart AOF, and converts some older encodings while loading data. These details matter to anyone evaluating the release because a working client connection does not establish compatibility of recovery artifacts.

I value Redis for its established data structures and operational model. A persistence change deserves close attention precisely because ordinary commands can continue looking familiar while the files needed to restore their results change underneath them.

A manifest describes the append-only history

The RC1 AOF implementation documents three file roles. A base file represents a snapshot at the last rewrite. Incremental files hold subsequent write commands. History files are older base or incremental files that a successful rewrite has superseded.

The manifest records filenames, sequence numbers, and types. At most one active base file appears, and incremental files have an order. More than one incremental file can exist during a rewrite or after a failed rewrite before a later one succeeds. The file set is therefore not reducible to choosing whichever append-only filename has the newest modification time.

The RC1 configuration places these files in a dedicated directory selected by appenddirname. Its configured appendfilename supplies the naming basis. An example below shows the relevant defaults for naming and synchronization, together with enabling append-only persistence.

appendonly yes
appendfilename "appendonly.aof"
appenddirname "appendonlydir"
appendfsync everysec

The directory setting is an operational interface. A backup process that assumes all append-only state lives in the old single file would not describe the new layout. It needs to preserve the active files and their manifest as a coherent representation of persistence. The manifest supplies the relationship between files, while the files supply the data to replay.

History has a defined meaning as well. The implementation says that superseded files become history after a successful rewrite and are removed automatically unless garbage collection is disabled. Their presence does not mean that every file must remain active forever. Their role depends on the manifest's state and the rewrite lifecycle.

The release notes state that multipart AOF avoids rewrite overheads. The concrete structural change is that the rewritten base and the newer incremental history are separate artifacts. That separation lets the format represent a new base together with writes that belong after it. Understanding that relationship is more useful for recovery tooling than assuming every .aof file is independently sufficient.

The base format and synchronization policy are separate

Redis can create its append-only base in RDB or AOF format. The RC1 configuration enables the RDB preamble and describes that format as faster and more efficient. Consequently, an append-only deployment can include an RDB-format base plus incremental append-only files. The persistence mode's name does not imply that every active file contains only text commands.

The appendfsync policy remains a separate choice. The configuration describes no, always, and everysec, with the last as the default. Changing the layout does not select a different synchronization guarantee. A manifest can describe the right replay order without determining when the operating system has durably written each update.

Timestamp annotations are another independent option. RC1 adds aof-timestamp-enabled, disabled by default, to support point-in-time restoration. The configuration warns that enabling it changes AOF contents in ways existing parsers may not understand. An operator therefore has to consider both the container layout and the parser's supported records.

These distinctions affect external tooling. A program may recognize command records but not the manifest. Another may understand the directory and still reject timestamp annotations. Compatibility needs to identify which artifact and format the tool consumes instead of treating all persistence support as a single yes-or-no property.

Functions introduce named libraries

RC1 adds the FUNCTION command family together with FCALL and FCALL_RO. The tests in the RC1 tag show the interface present in this candidate. A library is loaded with an engine name, library name, and code that registers a function. Calling it then uses the function name and a count of key arguments.

The following commands reproduce the simple pattern exercised by those tests. They are written for this candidate's command syntax.

FUNCTION LOAD LUA greeting "redis.register_function('hello', function(keys, args) return 'hello' end)"
FCALL hello 0

The zero says that this invocation supplies no keys. The library name and registered function name have separate roles. A library groups loaded code, while FCALL selects the registered function. The tests also cover replacement and deletion, making library lifecycle part of the interface rather than leaving it entirely with the client.

The Functions implementation includes dump and restore support. Its dump format represents libraries with their names, engine information, descriptions, and code. The payload uses RDB-style serialization with a version and checksum. This makes the stored program an artifact that can be exported and restored through a defined interface.

That lifecycle changes the operational question around server-side code. A deployment needs to know which library is loaded and which registered names its application calls. The library is not merely an implementation detail of a single client request. Its presence affects the commands that other clients can invoke.

Server-side execution still needs bounded behavior

The RC1 configuration describes a time limit for long-running scripts and functions before Redis begins handling or rejecting other clients. Reaching that limit does not imply that arbitrary execution can safely be terminated. FUNCTION KILL, like script termination, can stop execution only before it has issued write commands. After writes, the configuration identifies shutdown without saving as a possible remaining administrative action if execution does not finish.

This is a constraint on the programming model. Registering code as a Function does not turn a long synchronous operation into background work. The database still has to preserve a meaningful outcome for writes already performed. A time limit used to recognize an overlong operation is consequently different from a transaction deadline that can always abort it.

I prefer treating a Function library as deployed database code with its own lifecycle. Its registration and persistence make that responsibility visible. The callable name can remain stable while the implementation changes, so library replacement needs the same care as changing another component the application depends on.

Command metadata describes how clients use the code

RC1 also introduces key specifications in command metadata. The release notes describe these as a way for clients to locate key arguments and identify their read or write purpose. That information matters when a command takes more than one kind of argument. A client cannot route an operation correctly merely by assuming every argument after the command name represents a key.

Functions make the distinction visible at invocation through their explicit key count. Built-in command metadata addresses the corresponding problem across Redis commands. These interfaces describe the operation to the caller, while the persistence interfaces describe the artifacts needed by the server. A client can understand one without establishing compatibility with the other, which is why a release evaluation needs to keep both interfaces in view.

Recovery compatibility extends beyond command syntax

The release notes warn that the new RDB version is incompatible with older Redis versions. They also describe converting ziplist-encoded keys to listpacks when loading older RDB data, whether from disk or through replication. Reading older input and producing output an older server can read are separate compatibility directions.

That distinction prevents a misleading conclusion from a successful forward load. The newer server may load an older dataset while writing persistence that the older server does not understand. A rollback plan must account for the produced artifacts, not only the source dataset that originally started the instance.

RC1 makes these changes available for evaluation together. Multipart AOF gives persistence a manifest and an ordered file set. Functions give server-side code a named library lifecycle and serialization. Both require tooling to understand the structure of the artifact it preserves, including the version and relationships needed when Redis loads it again.