Why Redis 8.2 matters now for developers choosing between Memcached and Valkey
Redis 8.0 introduced AGPL licensing and vector sets, altering the cache landscape. Developers must weigh Redis advanced features against Valkey BSD-3 stability and Memcached simplicity, noting that Memcached lacks persistence and suffered a 1.35 Tbit/s DDoS attack in 2018.
Redis version 8.0, released in May 2025, changed the licensing landscape by adding the GNU Affero General Public License as a third option alongside the Redis Source Available License v2 and Server Side Public License v1. This tri-licensing move followed a period where the core software shifted from BSD-3 to source-available terms in March 2024, a change that directly triggered the Linux Foundation to fork the last BSD-licensed release as Valkey. The original author, Salvatore Sanfilippo, returned to the project in December 2024 after stepping down in 2020, bringing his expertise back to a codebase that now supports vector sets and JSON documents within a single package. For developers evaluating cache infrastructure, the decision hinges on whether you require the advanced data structures of Redis or prefer the strict open-source guarantees of Valkey and Memcached.
Licensing and architectural divergence
The shift to AGPL in Redis 8.0 was a strategic response to forks that had created a "level playing field" of differentiated products. Redis Ltd. cited record growth since the initial license change, suggesting that the commercial pressure drove the return to a more permissive copyleft model. However, the previous era of RSAL and SSPL licenses explicitly prohibited using the modules as part of a database, caching engine, or search engine without a commercial agreement. This restriction forced many organizations to evaluate alternatives like Valkey, which maintains the BSD-3 license and offers a stable, community-driven path forward.
Memcached remains a viable option for pure key-value caching, operating as a distributed memory system with a simple client-server architecture. It uses consistent hashing to distribute keys across multiple servers, ensuring that each key maps to the same server even when nodes are added or removed. Unlike Redis, Memcached lacks persistence mechanisms; if a server restarts, all cached data is lost, making it strictly a volatile store. The system relies on an LRU eviction policy to manage memory, discarding the least recently used items when capacity limits are reached. While this simplicity allows for quick deployment and low overhead, it leaves applications responsible for handling cache misses and data consistency with primary databases.
| Feature | Redis 8.x | Valkey | Memcached |
|---|---|---|---|
| License | AGPL / RSAL / SSPL | BSD-3 | Revised BSD |
| Persistence | RDB and AOF | RDB and AOF | None |
| Data Types | Strings, Hashes, Sets, Vectors, JSON | Strings, Hashes, Sets | Key-Value Pairs |
| Replication | Master-Replica Tree | Master-Replica | No Built-in Replication |
Performance and operational complexity
Redis operates primarily in memory, achieving sub-millisecond latency for reads and writes due to its efficient data structures and event-driven execution model. The inclusion of vector sets in recent versions positions Redis as a strong candidate for AI workloads, supporting retrieval augmented generation and semantic caching directly within the cache layer. Developers can use Lua scripts to execute complex logic on the server side, reducing network round trips and improving throughput for high-frequency operations. The cluster mode, introduced in version 3.0, scales up to 1,000 nodes, providing write safety and continued operation during node failures.
Valkey inherits the same performance characteristics as the pre-8.0 Redis versions but without the licensing ambiguity. It supports master-replica replication, allowing data to replicate to any number of replicas for read scalability and redundancy. This makes it suitable for applications that need durable caching without the commercial constraints of Redis’s source-available licenses. Memcached, by contrast, does not support replication or fault tolerance natively. If a node fails, the application must handle the loss of data, often requiring redundant clusters or external monitoring tools to maintain availability.
I find the security posture of Memcached particularly concerning for modern deployments. In February 2018, misconfigured servers were used to launch DDoS attacks with an amplification factor exceeding 51,000, flooding victims like GitHub with 1.35 Tbit/s of traffic. Although version 1.5.6 disabled UDP by default to mitigate this, the flat trust model means that any client with valid access can retrieve all entries, including those with higher security requirements. This lack of granular access control forces administrators to rely on network segmentation and IP whitelisting, adding operational complexity that Redis and Valkey address through more robust authentication options.
Does the return of the original maintainer to Redis signal a long-term commitment to open-source principles, or is it merely a tactical adjustment to market pressures? The answer likely depends on how the AGPL terms are enforced against managed cloud providers over the next few years. For now, teams needing vector search and rich data structures should look at Redis 8.x, while those prioritizing license freedom and simple caching should stick with Valkey or Memcached.