Some open-source projects are hesitant to talk about how they use AI to improve their code. Not Valkey. Its developers are proud AI users. 

Prague — Valkey, in case you don’t know, is an open-source, high-performance, in-memory key-value data store used as a database, cache, message broker, and streaming engine. It’s a community-governed fork of Redis, hosted by the Linux Foundation and released under the permissive BSD 3-Clause license. Looking ahead, the Valkey team is using AI to improve its code, drastically cut down its memory usage, and, of course, make it more suitable for AI deployments. 

In an interview at ValkeyConf, Valkey’s developers are preparing a November release. This follows the first release candidate, Valkey 9.2.0-rc1, which rolled out the door on September 16. At the top of the list of improvements in this release is Valkey tackling one of the in-memory data store’s most expensive operational problems: the extra memory needed to save a snapshot while applications continue writing data. 

The headline infrastructure change is forkless relational database (RDB) snapshotting, an opt-in alternative to creating a child process to save the database. The release candidate adds the forkless-infrastructure-enabled and bgsave-default-method configuration options, along with persistence information reporting the save method and progress. 

It’s not that Linux’s fork() isn’t fast enough. It’s plenty fast enough. Nor is it how it handles duplicating an entire database in physical memory. Nope, the memory overload comes when subsequent writes force memory pages to be copied while the snapshot is being saved. For a busy cache, those copy-on-write allocations can become way too expensive.

As Madelyn Olson, Valkey’s co-founder, explained, this high write rate can, in the worst case, double the database’s memory footprint as pages are copied. This can lead to thrashing–and heavens forbid–swapping to storage, which can bring jobs to a crashing halt. 

To avoid this memory calamity, Olson said, “A lot of people use the old heuristic that they will reserve 50% memory just for this snapshot process. Our goal is to basically bring that down to like 10 to 15%.”

Jacob Murphy, a Google engineer and full-time Valkey maintainer, added, “We found that some of our older, slower CPUs take quite a long time to pause, and that can also be a big problem. You see a lot of timeouts during that initial freeze the world phase.”

On top of this, the forthcoming Valkey 9.2 also introduces a prefix-aware data type for AI workloads, more efficient sorted sets, and new administrative controls. The biggest add-on here is Path Hash. This is a new radix-tree-backed data type that’s handy for exact lookup, longest-prefix matching, and prefix traversal over binary-safe paths.

This new data type can be used for prefix indexing. Traditionally in Valkey, hashes represent objects with attributes and single keys, where the system doesn’t know the hierarchy. This differs from an ordinary hash, which provides field-based access without inherently expressing a prefix hierarchy. In the interview, a contributor described large language models (LLMs) key-value caching as a new data type that will lead to LLMs working more efficiently with Valkey workloads. 

Beyond the individual features, what’s interesting in Valkey 9.2 is that the developers describe it as a release shaped by AI-assisted coding, review, and maintenance. They’re not simply generating more code. 

Valkey isn’t doing this with a single LLM. Instead, each developer and maintainer is using their own favorite AI. Murphy explained, “Everyone comes as a contributor with their own AI code generation stack.” 

How well does it work? The maintainer in charge of the new data type said that producing the new data type’s code took roughly a week, followed by about two weeks of discussion. That’s a fraction of the time it would have taken had it been done by human hands alone. 

Besides writing new code, Olson said Valkey is also applying AI to adversarial testing, automated code review, and backporting. The review tooling is tuned to find functional bugs rather than overwhelm developers with stylistic complaints. “One of our goals with that is to have very low false positives,” she said, and that’s what they’ve done. 

AI is also helping maintain code across Valkey seven (count ’em, seven) supported releases. Olson estimated that the project had backported about eight times as many commits in the preceding six months as it had in its earlier history, helped by automation.

But increased output creates its own pressure. Better bug-finding tools produce more reports, while coding assistants generate more pull requests that still require maintainer attention. “I don’t think anyone’s happy with that amount of effort we’re putting in,” Olson said of the work needed to keep pace.

For Valkey 9.2, the release-candidate period is therefore more than a final packaging exercise. Developers are using AI-automated testing and external researchers to uncover problems before general availability. The published notes already include fixes involving snapshot compression, the new B+ tree implementation, cluster behavior, and access-control checks.

For Valkey, AI development tools have proven successful. Maybe it can for your projects too.