Server — Redis

Most of the infrastructure on February was chosen without significant controversy. MariaDB is MariaDB. WireGuard is WireGuard. Borgbackup is Borgbackup. Redis is more complicated, because in March 2024 Redis Ltd. changed the licence on the Redis codebase from the BSD 3-Clause licence to a dual RSALv2/SSPL model, making it effectively proprietary for anyone offering it as a managed service. The response was significant: the Linux Foundation launched Valkey, a BSD-licenced fork of the last open-source Redis release, backed by AWS, Google Cloud, Oracle, Ericsson, and much of the original Redis contributor community.

By mid-2026, Valkey 8.1 is in production use at scale, the two projects have diverged meaningfully in their architecture, and every team that runs Redis is making a decision about this whether they acknowledge it or not.

This article is the introduction: what an in-memory data store is and why February might need one, an honest account of the Redis/Valkey situation, and a clear recommendation. The install article that follows acts on that recommendation.

What an in-memory data store is

MariaDB stores data on disk. Reads and writes involve the InnoDB buffer pool, the redo log, and ultimately the storage hardware. This is fine for persistent relational data, but it is the wrong tool when you need fast ephemeral storage: caching the result of an expensive query, storing a session token, tracking a rate limit counter, or passing messages between application components.

An in-memory data store keeps all its data in RAM. Reads and writes are orders of magnitude faster than a disk-backed database because there is no IO involved. The tradeoff is that RAM is finite and more expensive than disk, and the data is not durable by default: a process crash or server restart loses everything unless persistence is explicitly configured.

The use cases where this trade makes sense are the ones where speed matters more than durability. A cache entry is worthless after the data it caches has changed; losing it on restart costs nothing. A session token needs to be read on every HTTP request; a disk round-trip for each one would be a meaningful performance bottleneck. A rate limit counter needs to be incremented atomically thousands of times per second; MariaDB could do this but it is not what MariaDB is optimised for.

What February might use it for

The specific use case is not decided yet, and that is fine. The more honest framing is: as February adds more services, some of them will benefit from or require an in-memory data store. Common patterns include:

Application caching. A web application that queries MariaDB for content can cache the results in Redis for a configurable TTL. Subsequent requests are served from memory without touching the database.

Session storage. Web applications that need to track logged-in users typically store session data somewhere. Redis is the standard choice: fast, supports expiry natively, and does not require a schema.

Queue and pub/sub. Applications that need to pass messages between components, or run background jobs, can use Redis as a lightweight message broker. It is not a replacement for RabbitMQ or Kafka at scale, but for a homelab server it is more than sufficient.

Rate limiting. Any service exposed to the internet needs rate limiting. Redis’s atomic increment operations and key expiry make it the standard tool for implementing token bucket or sliding window rate limiters.

Leaderboards and counters. Redis sorted sets make certain data structures trivial that would require complex queries in MariaDB. This is a niche use case but worth knowing about.

February probably does not need all of these right now. It will need at least one of them as the service list grows.

Redis and Valkey: the honest account

In 2024, Redis Ltd. changed the Redis licence from BSD to RSALv2/SSPL. The SSPL requires any organisation offering Redis as a service to open source all the software involved in providing that service, which is a requirement most commercial operators cannot or will not meet. For self-hosted users running Redis on their own infrastructure and not offering it as a service to others, the licence change has no practical legal impact. You can still run Redis on February without any licence concern.

The issue for a homelab series like this one is not legal but philosophical. The ethos of this series has been open source throughout: software you own, can inspect, can modify, and are not beholden to a single commercial vendor for. MariaDB is open source. WireGuard is open source. Borgbackup is open source. Redis is no longer open source in the traditional sense.

Valkey was forked from the last open-source Redis release, Redis 7.2.4, and is maintained under the BSD licence by the Linux Foundation with contributions from AWS, Google, Oracle, and others. The two projects have diverged meaningfully since the fork: Valkey focuses on core engine performance, threading, and memory efficiency, while Redis has integrated its Stack modules into the core distribution. As of early 2026 they remain about 90% compatible at the command level, which means most applications that work with Redis work with Valkey without modification.

The recommendation

Use Valkey.

For February’s use cases, the command-level compatibility means the choice is transparent to applications. Valkey is BSD-licenced, Linux Foundation governed, and has no risk of further licence change. The performance work in Valkey 8.x is real and meaningful for high-throughput deployments, though February’s workload will not stress either project enough to notice the difference.

The one scenario where this recommendation does not hold: if a specific application explicitly requires Redis Stack modules, specifically RediSearch, RedisJSON, or RedisTimeSeries, and there is no Valkey-compatible equivalent. The Valkey module ecosystem is still maturing, and the compatibility gap is real if you have built on top of those modules. For February’s current and anticipated workload, none of those modules are in use.

Install Valkey. The install article uses the Valkey package rather than the Redis package. The configuration, the client libraries, and the operational patterns are identical. Applications that say they require Redis will work with Valkey.

What this is not

An in-memory data store is not a replacement for MariaDB. The two serve fundamentally different purposes. MariaDB is for data that needs to be durable, relational, and queryable. Valkey is for data that needs to be fast, ephemeral, and simple. Adding Valkey to February is adding a second tool that covers a different set of problems, not replacing the database with a faster one.

It is also not a queue, a message broker, or a time-series database in the way that dedicated tools for those purposes are. Valkey can serve all of those roles adequately for a homelab server. For production workloads at scale, dedicated tools exist for each. February is not a production workload at scale.