# Redis vs Valkey for WordPress: what actually matters

Redis has been the usual choice for a persistent WordPress object cache for more than a decade: the first Redis object cache drop-ins appeared in 2014, and the most popular one runs on half a million sites today. As the store behind a page cache it is still the exception, which is the case MilliCache makes. Since 2024 Redis has a fork, Valkey, that speaks the same protocol, carries a more permissive license and is backed by the largest cloud providers. A growing number of hosts now install the fork instead of the original, which is how a server nobody asked for ends up in control panels, and how "Redis or Valkey?" became a question site owners have to answer.

For a WordPress page cache or object cache, the two are interchangeable. That is the short answer, and it is unsatisfying on its own. What follows is the reasoning: why this family of servers is such a good fit for caching in the first place, why the fork exists, what "drop-in compatible" covers at the protocol level, where the two have since diverged, and the few cases where the choice does tilt one way.

## Why an in-memory key-value store is the right home for a cache

Before comparing the two, it is worth being clear about what makes either of them worth running. Redis, started by Salvatore Sanfilippo in 2009, solved one problem exceptionally well: keep data in memory, address it by key, and answer in microseconds. Commands execute on a single thread, one after another, so there are no locks to contend for and no surprises in latency. On the same machine, a lookup costs tens of microseconds, an order of magnitude below even a trivial database query, and with none of the variance that comes from disk.

The second strength is the protocol. RESP is a plain-text protocol simple enough to speak over telnet, which is why every language has a client, why those clients are small and stable, and why a fork can be fully compatible without copying anything but the specification. The third is that the server stores data structures, not just blobs: strings, hashes, sets, sorted sets, each with atomic operations and a built-in lifetime. A cache needs exactly those primitives, and we walked through how a page cache uses them in [Redis page caching for WordPress](/blog/wordpress-redis-page-cache/).

Then there is maturity. Fifteen years of production use at every scale, one binary with no dependencies, a few megabytes of memory when idle, a complete cache configuration in a handful of lines. Every ops team knows how to run it, every host offers it, every cloud has a managed version, every container platform has an image. That ubiquity is the context for the rest of this post: the software became important enough that a license change produced a fork within a week, and its design is simple enough that the fork could stay compatible.

## Why Valkey exists: the Redis licensing timeline

For fifteen years Redis was BSD-licensed open source, and it became infrastructure the way nginx or MySQL did: every host offered it, every language had clients, every tutorial assumed it.

In March 2024, the company behind Redis relicensed the core, starting with Redis 7.4, from BSD to a dual source-available model: RSALv2 and SSPLv1. Neither is an OSI-approved open source license. The practical target was cloud providers reselling Redis as a service, not site owners, but the change still meant the project as a whole was no longer open source.

Within a week, the Linux Foundation announced Valkey: a fork of Redis 7.2.4, the last BSD release, backed by AWS, Google, Oracle, and Ericsson among others, and kept under the BSD-3 license. Many Redis core contributors moved to the fork.

The story then took a turn: in May 2025, Redis 8 added AGPLv3 as a third licensing option, which is OSI-approved. So Redis is, by that definition, open source again. By then Valkey had a year of independent releases, cloud provider backing, and its own roadmap. The fork did not fold back in. As of 2026, Redis is on its 8.x line and Valkey is on its 9.x line, and both are actively developed.

That is the whole origin story, and note what is absent from it: no technical dispute, no incompatibility, no security incident. Valkey exists because of licensing and governance, which is exactly why the two remain so similar where it counts.

## What "drop-in Redis replacement" actually means

"Drop-in compatible" gets used loosely in this industry, so it is worth pinning down what Redis and Valkey compatibility concretely covers:

- **Wire protocol.** Valkey speaks RESP2 and RESP3, the same protocols Redis clients use. A client cannot tell which server it is talking to unless it asks.
- **Commands and API.** The command set WordPress tooling relies on (`GET`, `SET`, `EXPIRE`, sets, hashes, `SCAN`, pipelines, Lua scripting) behaves identically, because Valkey inherited the implementation rather than reimplementing it.
- **Data types and semantics.** Strings, lists, sets, hashes, sorted sets, TTLs, eviction policies like `allkeys-lru`: same types, same behavior, same configuration directives.
- **PHP clients.** phpredis and Predis connect to Valkey unchanged. No fork-specific client exists because none is needed.

The one compatibility edge worth knowing about is persistence files. Valkey reads RDB snapshots from Redis 7.2 and earlier, but Redis changed its RDB format in 7.4, so snapshots from newer Redis versions do not load into Valkey. For databases this complicates migration. For a cache it is a non-event: the recommended cache configuration disables persistence entirely, and everything in the cache can be regenerated. Migrating a WordPress cache from Redis to Valkey means pointing the same host and port at the new server and letting the cache warm back up.

## Redis vs Valkey today: where they have diverged

Two years of separate development have produced real differences, mostly at the edges of the feature set rather than the core.

Redis has folded the capabilities that used to live in separate modules into the main product: JSON documents, search and query, probabilistic data structures, vector sets for AI workloads. Valkey offers the same ground as loadable modules (valkey-json, valkey-search, valkey-bloom, valkey-ldap, all at 1.0 and shipped together in the official valkey-bundle image), so the difference is packaging and the finer details of each feature, not whether the feature exists.

In the core, Valkey has concentrated on the key-value workload itself, with I/O threading to push more throughput out of multi-core machines, plus memory efficiency improvements across its 8.x and 9.x releases. Redis has kept its own performance work going in parallel. Benchmarks trade the lead back and forth depending on the workload and who ran them.

Now apply that to what WordPress actually asks of this server. A page cache stores rendered HTML as strings and uses sets for invalidation. An object cache stores serialized PHP values with TTLs. No JSON documents, no search indexes, no vectors. And the throughput ceiling of either server is orders of magnitude above what a WordPress site generates; the bottleneck is PHP and MySQL, never the key-value store. The areas where Redis and Valkey have diverged are precisely the areas a WordPress cache never touches.

## Valkey as a service: the managed landscape

Where the fork has visibly reshaped things is managed hosting, which makes sense given who backed it.

AWS ElastiCache offers Valkey at a lower price than its Redis-branded option. Google Cloud Memorystore supports Valkey alongside Redis. DigitalOcean and Aiven run managed Valkey. Meanwhile, shared and managed WordPress hosts have been quietly swapping their bundled Redis for Valkey, which is how the unfamiliar name turns up in control panels.

This is the practical answer to "which one will a site actually run": increasingly, whichever one the platform hands out. A host that provisions Valkey gives no reason to fight it. A host that provisions Redis, same answer.

## Dragonfly: the other compatible option

Redis compatibility is a protocol, not a product, and one more server speaks it well enough to sit under a WordPress cache.

**Dragonfly** is not a fork but a from-scratch implementation of the Redis API, under the Business Source License, designed for memory efficiency on large datasets. It works with standard Redis clients. KeyDB, the older multithreaded fork that used to appear in these comparisons, has been dormant since its last release in 2023 and no longer belongs on a shortlist for new setups.

| Server | License | What it is | Fits when |
|---|---|---|---|
| Redis | AGPLv3 / RSALv2 / SSPLv1 | The original, widest support | The most documented default is wanted, or it is already running |
| Valkey | BSD-3 | Linux Foundation fork of Redis 7.2 | A permissive license matters, or the platform defaults to it |
| Dragonfly | BSL | Redis-compatible reimplementation | Memory efficiency on very large caches |

For a typical WordPress site, the honest assessment is that Dragonfly's headline strength solves a problem it is unlikely to have. A few hundred megabytes of cached pages does not stress anyone's memory allocator. It is worth knowing about, and it works, but it is not a reason to leave the Redis and Valkey mainstream.

## How to decide for a WordPress site

Given all of the above, the decision tree is short:

- **The host or cloud platform already provides one of them:** that one. The operational difference for a cache workload is zero.
- **Self-managed server, and the license matters to the organization:** Valkey. BSD-3 is the simplest possible answer, with no license lawyer required.
- **A Redis instance is already running and healthy:** keep it. A working cache gains nothing from a migration, and the license question only concerns the people distributing the software.
- **Still undecided:** either. Switching later costs one config change and a cache warm-up.

  

 

 Tip:Whatever the pick, the server tuning is identical: cap memory with `maxmemory`, set `maxmemory-policy allkeys-lru` so old entries get evicted instead of writes failing, and disable persistence, since a cache can always be regenerated. The [storage backends guide](/docs/millicache/08-storage-backends/01-overview) has the full recommended configuration.

 

 

 

This neutrality is also how MilliCache treats the question. It talks RESP and works with any Redis-compatible server: Redis, Valkey, Dragonfly, or anything else that answers the protocol. The connection configuration does not know or care which one is listening:

 wp-config.php 

 

```
 1define( 'WP_CACHE', true );
 2
 3// Identical whether Redis or Valkey answers on this port.
 4define( 'MC_STORAGE_HOST', '127.0.0.1' );
 5define( 'MC_STORAGE_PORT', 6379 );
 6
 7// Managed service with TLS, e.g. ElastiCache for Valkey:
 8// define( 'MC_STORAGE_HOST', 'tls://master.example.cache.amazonaws.com' );

```

Unix sockets, authentication, and TLS follow the same rule: one set of constants, any compatible backend. `wp millicache test` reports the same result after pointing it at either server.

---

## Try it

**MilliCache** is a full-page cache for WordPress built on exactly this storage layer: it stores rendered pages in Redis, Valkey, or Dragonfly and serves them before WordPress loads. The [storage backends guide](/docs/millicache/08-storage-backends/01-overview) covers every backend, connection option, and the recommended server configuration, and the [installation guide](/docs/millicache/01-getting-started/20-installation) gets a site from zero to cached in a few minutes.

**MilliCache Pro** adds replication and Sentinel failover for high-availability setups, and many more improvements such as cache preloading, a persistent object cache on the same server, and detailed metrics.

[ Compare MilliCache and MilliCache Pro ](/millicache-pro/#compare)