Posted on nosqlgooglealerts. Visit nosqlgooglealerts

Interview Version 8.1 of Valkey was recently released, marking a year since the creation of the Redis fork. Valkey’s co-maintainer, Madelyn Olson, is looking ahead to version 9 as the project settles down.

The forking of the Redis in-memory database, caused by the company’s controversial decision to tighten license terms, resulted in an exodus of contributors, including Olson, an AWS Principal Engineer and former Redis maintainer. Olson is now a co-maintainer of Valkey, which has since released several updates, including versions 8.0 and, most recently, 8.1.

We spoke to Olson before Redis announced that it would be switching to the GNU Affero General Public License (AGPL).

Valkey’s creation not only freed the database from the Redis steering committee but also resulted in a large number of pent-up requests for functionality being unleashed, some of which had been held up by Redis Open Source.

“There was definitely a big wave of stuff that kind of happened right after the fork, and right after 8.0,” recalls Olson during a chat with The Register at this year’s Kubecon EU event in London.

“Another thing that was explicitly blocked by the old steering committee of Redis Open Source was an observability feature we built in 8.0 for slot statistics.

“So slots are on shards. When you’re doing rebalancing, you want to figure out which slots are the hottest, and then make sure those are well balanced.

“We wanted to build a feature so you could easily and quickly tell which slots were hot and so how to rebalance them.

“And that got blocked before, but that was one of the first things that got built in 8.0 because it was like, well, new group, new folks, let’s build a thing!”

It seems an obvious feature. Why did it get blocked?

“It really came down to this very small performance cost that some folks did not want to pay … I think it came down to a sort of philosophy difference.”

Valkey 8.0 and now 8.1 feature performance improvements that Olson reckons more than cancel out the cost of adding observability, particularly since that observability is extremely useful when it comes to performance tuning.

“Most workloads that I see,” she says, “are bottlenecked on the storage … like ‘how much data can you stick in the engine?’ And most people aren’t hitting the CPU limits, so we do have some CPU cycles to spare to do extra work.

“But some people felt that that [the performance cost] was the more important thing to focus on. So it did really come down to trade-offs.”

And what of the early days of Valkey?

“The first six months were a lot of work,” says Olson. “I was completely burned out after it.”

Olson isn’t just talking about the work to get version 8.0 released, but the effort to build a community around the project.

“I really did not want this to be a single vendor project,” she explains. “We wanted to make sure that we weren’t having this private little group that controlled everything.

“So we were trying to be more inclusive, adding more maintainers, adding more people to the Technical Steering Committee … we’re trying to make sure it’s not all bottlenecked on one person.

“And I think that’s the best way to avoid burnout: making sure that everyone in the community is working on it, and also everyone feels empowered that they’re making a difference.”

Olson was joined by Ricardo Dias, a Principal Software Engineer from Percona, and now a Valkey contributor. “My role,” he says, “is to work full-time on the community project to help build things – whatever is needed; features, bug fixes, whatever there is to do.”

While Percona does not plan to build its own distribution of Valkey, it will provide support and professional services for the platform. And support is a factor that looms large in the minds of many enterprises.

Olson acknowledges the support factor. “One of the things that we did with Valkey was ask around: ‘Hey folks, what would convince you to move?’ And a lot of people said, ‘If you gave us five years of support, yeah, we’ll move.’

“The current plan is for all versions to get at least three years, which we think is OK, and then we’ll designate the last minor of each major that we officially support as a five-year version.”

This raises the question of whether there will be an 8.2 or if Valkey will move to version 9.

“The current thinking is we’ll do a nine release based on some changes we want to make that we think are a little bit more intrusive,” Olson says.

The specter of breaking changes looms large over projects like Valkey and Redis. “Valkey,” explains Olson, “is also used extensively in queuing systems. You do not want that layer to go down.

“So we are just very conservative about what we put into a version, so we try to even make it clear that when we do a major version, there are as few changes you might even consider breaking as possible. We normally call them just like behavior changes, because it’s not, strictly speaking, a breaking API.”

Customers appear to be satisfied with the conservative approach, although Olson says Valkey does not capture any telemetry, so the team relies on feedback from users and managed providers. She gives an example of one user who deployed the latest version to production and reported that they were very pleased with the updates.

We contend that the customer is also very brave by deploying to production so soon.

Olson laughs: “You know, in the tech world, you’ve got to be brave sometimes!” ®