If your site does anything beyond serving static pages, something somewhere is running the same expensive database query or PHP computation over and over. An object cache exists to stop that waste — it stores the result of that work in memory the first time, then serves it straight from RAM on every subsequent request until it expires or changes. For WordPress specifically, an object cache means options, menus, term lookups, and plugin data stop hitting MySQL on every single page load.

Two tools dominate this layer: Redis and Memcached. Both are free, both are mature, both are genuinely fast, and both show up constantly in hosting control panels and WordPress caching plugins. They are not, however, interchangeable — they were built with different goals, they behave differently under load, and one of them has been through a very public licensing shake-up in the last couple of years that changes how you should think about it in 2026.

This guide breaks down what each one actually is, where they genuinely differ under the hood, how each integrates with WordPress and PHP hosting specifically, and which one makes sense for which kind of site. No tribal loyalty to either camp — just the practical facts.

1. What Each One Actually Is

Redis

Redis (REmote DIctionary Server) is not just a cache — it’s an in-memory data structure server. Alongside simple string values, it natively supports hashes, lists, sets, sorted sets, bitmaps, HyperLogLogs, geospatial indexes, and streams, and it can execute Lua scripts atomically on the server side. It also supports pub/sub messaging and, unlike a pure cache, optional persistence — meaning the dataset can survive a restart instead of starting empty.

Redis’s licensing has changed more than once in the last few years, and it’s worth being precise here since older articles are now out of date. Redis shipped under permissive BSD-3-Clause through version 7.2. In March 2024, Redis Ltd. moved to a dual license — RSALv2 or SSPLv1 — neither OSI-approved. The move aimed to stop cloud providers reselling Redis without contributing back, but it triggered backlash and led AWS, Google, Oracle, and others to fork the last BSD-licensed codebase into Valkey, now maintained by the Linux Foundation as a permanently open-source, BSD-licensed, drop-in-compatible alternative. In 2025, Redis Ltd. partly reversed course: starting with Redis 8, Redis Open Source ships under a tri-license — RSALv2, SSPLv1, or AGPLv3 — restoring an OSI-approved option. Practically: current Redis is open source again under AGPLv3, but Valkey remains the more permissively-licensed, community-governed option many cloud providers already standardized on. When this guide says “Redis,” most of it applies equally to Valkey — the two are wire-compatible for object-caching purposes.

Memcached

Memcached is older and far simpler by design. It was built in 2003 (originally for LiveJournal) to do exactly one job: store key-value pairs in memory and serve them back as fast as possible. There are no lists, no hashes, no sorted sets, no persistence, and no scripting — a value is a blob of bytes attached to a key, with an expiration time. That’s the whole feature set, plus atomic increment/decrement on numeric values. Memcached has always been released under a permissive BSD-style license, and that hasn’t changed — it was never part of the licensing controversy that reshaped the Redis ecosystem.

What Memcached gives up in features, it makes up for in architectural simplicity: it has been multithreaded since version 1.4 (released in 2009), meaning a single Memcached process can spread simple get/set traffic across multiple CPU cores natively, without any client-side sharding logic.

2. How They Actually Differ

The feature list above hints at the real divide: Redis was designed to be a flexible in-memory data platform that also happens to work brilliantly as a cache. Memcached was designed to be nothing but a cache, and to be extremely good at that one thing.

The Threading Question

This is one of the most misunderstood differences, so it’s worth being precise. Redis executes commands on a single main thread — this is deliberate, because it guarantees that operations like an atomic increment or a multi-key transaction can’t be interleaved and corrupted by another thread. Since Redis 6 (2020), Redis has added optional multi-threaded I/O, meaning it can use additional threads to read requests off the network and write responses back to it, reducing a bottleneck that used to exist purely on the networking side — but the commands themselves still execute one at a time on the main thread. Memcached, by contrast, has been genuinely multithreaded at the command-execution level since 2009, letting independent worker threads serve simple get/set requests in parallel across CPU cores.

What “Simple” Actually Buys You

Memcached’s minimalism isn’t a limitation so much as a deliberate trade-off: because it does less per operation, its multithreaded architecture can push more raw simple-operation throughput per server core in some benchmarks. Redis trades away some of that raw simplicity for the ability to do far more work per network round-trip — an advantage that grows as your caching needs get more sophisticated than plain get/set.

3. Performance Compared

“Which one is faster” is the wrong question, because the honest answer is: it depends what you’re asking it to do.

Simple, High-Volume Get/Set Traffic

For pure, high-concurrency key-value lookups spread across many CPU cores, Memcached’s multithreaded architecture can extract more raw throughput per server, since it was purpose-built for exactly that pattern with almost no overhead per request.

Anything Beyond Plain Get/Set

Redis’s advantage shows up when an operation would otherwise take multiple round-trips with Memcached. An atomic counter, a hash field update, a sorted-set insert, or a Lua script touching several keys all happen in a single round-trip to Redis. The equivalent with Memcached usually means fetching a value, modifying it in application code, and writing it back — more network hops, with no guarantee another process didn’t change the value in between. For workloads needing more than “get this blob, set that blob,” Redis often ends up faster in practice despite single-threaded command execution, simply because it needs fewer trips to get the job done.

4. Data Structures & Capabilities

This is the clearest, least contentious difference between the two. Memcached stores byte strings against keys, full stop. Redis stores several genuinely useful data types natively:

• Strings — the same basic type Memcached offers, plus atomic increment/decrement and bit operations.
• Hashes — field-value maps, ideal for representing an object (a user record, a product) without serializing and re-parsing the whole thing on every read.
• Lists — ordered collections, usable as simple queues or activity feeds.
• Sets and sorted sets — unique collections, with sorted sets adding a score for ranking — the basis for leaderboards, rate limiters, and priority queues.
• Streams — an append-only log structure suited to event data and lightweight message queues.
• HyperLogLogs and bitmaps — memory-efficient structures for approximate counting and flag-style tracking at scale.

# Simple string cache — this is the only pattern Memcached also supports
SET user:42:name "Jane Doe"
GET user:42:name
EXPIRE user:42:name 3600

# A hash — store a whole object without re-serializing it every time
HSET user:42 name "Jane Doe" plan "pro" logins 14
HGET user:42 plan
HINCRBY user:42 logins 1

# A sorted set — this is a full leaderboard update in one round-trip
ZADD leaderboard 4200 "user:42"
ZREVRANGE leaderboard 0 9 WITHSCORES

Memcached’s equivalent command set is much smaller — set, get, add, replace, delete, and incr/decr on numeric values, plus a gets/cas pair for basic optimistic-locking. That’s genuinely enough for a huge share of caching needs, including most of what WordPress’s object cache does. But it means anything resembling a leaderboard, a rate limiter, a job queue, or a structured object update has to be built in application code with Memcached, where Redis just does it natively in one command.

5. Persistence & Durability

Memcached: Nothing Survives a Restart

Memcached keeps everything purely in RAM with zero persistence mechanism. Restart the process, and every cached value is gone — it has to be rebuilt from the origin (your database) as requests come back in. For a pure object cache, this is by design and usually fine: the cache is supposed to be disposable, and WordPress falls back to querying the database directly when a value isn’t cached. The one real risk is a “cold cache stampede” right after a restart, when a burst of traffic all misses the cache at once and hits the database simultaneously.

Redis: Persistence Is Optional, Not Mandatory

Redis can run exactly like Memcached — pure in-memory, no persistence, wiped on restart — or it can be configured to persist its dataset to disk using RDB point-in-time snapshots, an append-only file (AOF) that logs every write, or both together. For a plain WordPress object cache, persistence is usually turned off or simply irrelevant, since the cached values are disposable derivatives of database data anyway. It starts to matter when Redis is doing double duty — as a session store, a rate-limiting counter, a lightweight job queue, or anything else where losing the data on restart would actually cause a problem rather than just a temporary cache miss.

# RDB snapshotting — save if 1+ keys changed in 900 seconds, etc.
save 900 1
save 300 10

# AOF — logs every write for finer-grained durability
appendonly yes
appendfsync everysec

# To behave exactly like a pure, disposable cache: disable both
save ""
appendonly no

6. Memory Management & Eviction

Both tools have to decide what to throw away once memory fills up — but they manage memory very differently under the hood.

Memcached’s Slab Allocator

Memcached divides its memory into fixed “slab classes” — chunks of pre-set sizes — and stores each value in the smallest slab class that fits it. This avoids memory fragmentation, but it has a well-known side effect sometimes called slab calcification: if your workload’s value sizes shift over time, memory that was allocated to one slab class can stay locked to that class even after it’s no longer the size you need, effectively wasting capacity until the process is restarted or slab reassignment kicks in. Eviction is LRU-based, applied per slab class rather than globally.

Redis’s Allocator and Eviction Policies

Redis uses a more flexible general-purpose allocator (jemalloc by default on Linux) rather than fixed-size slabs, avoiding the calcification problem entirely, though it comes with somewhat higher per-key memory overhead than Memcached’s leaner structure. Where Redis clearly pulls ahead is eviction control — maxmemory-policy lets you choose exactly how it behaves once memory fills up: noeviction (reject new writes), allkeys-lru or allkeys-lfu (evict least-recently or least-frequently used keys across the whole dataset), volatile-lru/volatile-lfu/volatile-ttl (evict only among keys that have an expiration set, prioritizing by recency, frequency, or nearest expiry), or allkeys-random/volatile-random. Redis 8.6 added a further pair — allkeys-lrm/volatile-lrm — which evict by least-recently-modified rather than least-recently-accessed, useful for write-heavy workloads. That granularity matters if the same Redis instance is holding both disposable cache entries and data you’d rather it never evict.

7. WordPress & PHP Integration

Neither Redis nor Memcached talks to WordPress on its own — WordPress needs a PHP extension to reach the cache server, and an object-cache drop-in (or a plugin that installs one) to route WordPress’s internal caching calls to it.

In practice, phpredis is the extension most hosts install and most performance guides recommend, since it's compiled and carries less overhead than the pure-PHP Predis library on every call. The Redis Object Cache plugin has become close to a de facto standard for WordPress Redis integration — actively maintained, handles clustering and Sentinel, and ships WP-CLI commands. WP Rocket doesn't ship its own object-cache backend, but its docs cover pairing WP Rocket's page caching with a separate Redis plugin, since the two work at different caching layers. LiteSpeed-powered hosts have a real advantage here: LiteSpeed Cache's WordPress plugin has object-cache support for both Redis and Memcached built directly into its configuration screen, no separate plugin required — see our LiteSpeed vs. Apache vs. Nginx comparison if you're evaluating that web server layer generally.

8. Hosting Availability

Unlike MySQL, which is bundled into nearly every hosting plan by default, object-cache servers are add-ons more often than defaults — which host offers what varies widely.

9. Multi-Server & Scaling Considerations

Redis Cluster and Sentinel

Redis has two distinct built-in tools for scaling beyond a single node. Redis Cluster shards data automatically across multiple Redis nodes using hash slots, so the dataset can grow beyond what one server's memory can hold, with the cluster itself aware of which node owns which keys. Redis Sentinel is a separate, related tool for high availability rather than sharding — it monitors a primary/replica Redis setup and handles automatic failover if the primary goes down. A deployment can use replication and Sentinel for HA without needing Cluster's sharding at all, which is the more common setup for a caching-only use case.

Memcached's Client-Side Sharding

Memcached servers don't know about each other at all — there's no clustering protocol built into Memcached itself. Instead, scaling across multiple Memcached nodes is handled entirely on the client side: the Memcached client library (built into the PHP extension) uses consistent hashing to decide which server in the configured pool a given key belongs to. This is simpler to reason about and requires no server-side coordination, but it also means there's no replication or automatic failover — if a node goes down, the keys it held are simply gone from the cache (rebuilt from the origin on the next request), which is generally an acceptable trade-off for something that's explicitly disposable.

For most WordPress installations — even fairly large ones — a single Redis or Memcached instance (or a primary/replica Redis pair for headroom and failover) is more than sufficient; multi-node clustering typically only becomes relevant once you're also dealing with genuinely large traffic spikes across a multi-server WordPress setup. If that's the situation you're planning for, see our guide on handling traffic spikes on WordPress hosting.

10. Use Case Verdicts

11. The Decision Framework

Work through these questions in order. Stop as soon as you have a clear answer.

Question 1: Is this purely a cache, or does it need to do more?

• Only caching database query results and computed values → either works; lean Redis for better plugin support
• Also need session storage, rate limiting, a lightweight queue, or pub/sub → Redis, Memcached architecturally can't do this
• Need the cache to survive a server restart without rebuilding from scratch → Redis with persistence enabled

Question 2: What does your hosting environment actually offer?

• On shared/cPanel hosting → check what's actually installed; don't assume either is available
• On a LiteSpeed-based host → both are natively supported in LiteSpeed Cache's Object Cache tab
• On a VPS, dedicated server, or cloud platform → your choice; both install easily, and Valkey is a valid Redis-compatible option

Question 3: How large and how "simple" is your traffic?

• Typical WordPress site, even fairly busy → the difference between the two is very unlikely to be your bottleneck
• Massive, multi-core, pure get/set volume at real scale → Memcached's threading model is a genuine advantage here
• Anything needing atomic multi-step operations (counters, leaderboards, structured updates) → Redis avoids extra round-trips

Question 4: What does your team already know?

If your developers or your host's support team are already comfortable operating one of these two, that familiarity is worth real weight — cache configuration, memory sizing, and troubleshooting evicted-too-early or connection-limit issues all take some accumulated experience. Switching backends for a marginal theoretical gain rarely pays for itself on a typical WordPress site.