Object Caches, Measured
Redis vs Memcached — two object caches, one job, different margins
Over a local socket both return a key in well under a millisecond, so raw speed will not pick your winner. The real comparison is persistence, data structures, threading — and which one your stack actually supports well.
The short answer
For WordPress and most PHP applications, choose Redis: performance is effectively equal for the get/set traffic an object cache generates, and Redis wins everything around it — a mature plugin ecosystem, persistence so a restart doesn't hand your database a cold-cache stampede, richer eviction policies, and data structures that earn their keep the day you need a queue or a rate limiter.
Memcached remains the right tool where its design is the point: a pure, multithreaded key-value cache that scales get/set across many cores with slightly leaner memory per entry. If you run it well already, there is no performance argument for switching. If you are choosing fresh in a hosting context, Redis is the boring, correct answer.
By the HostingFast team · Reviewed 25 August 2026
<1 ms
Round trip for both, over a local socket
Warm
Redis can restart without emptying the cache
Threads
Memcached scales pure get/set across cores
−90%
The order of query reduction a good object cache delivers
An object cache exists to stop your application re-asking the database questions it just answered. WordPress without one runs its full complement of queries per uncached request; with one, repeat lookups — options, post meta, user data — come from memory in microseconds. It is the highest-leverage change available for logged-in and dynamic traffic, which is exactly the traffic page caches cannot touch.
Redis and Memcached both do this job to a standard where the network hop, not the software, is the cost. Choosing between them on benchmark folklore misses the actual differences, which live in what happens on restart, under memory pressure, and when your needs grow past get and set.
The job: stop repeating database work
Every WordPress request rebuilds the same knowledge: autoloaded options, the current user, taxonomy maps, plugin settings. The database answers these queries quickly — and an object cache answers them ten to a hundred times quicker, from memory, without the query parser or the storage engine being consulted at all.
The effect concentrates where page caches cannot reach: wp-admin, logged-in users, carts and checkouts, REST and AJAX traffic. If your admin feels treacly or your store slows under logged-in load, this layer — not more CPU — is usually the missing piece.
Redis: a data-structure server that moonlights as a cache
Redis stores lists, hashes, sets and sorted sets, not just strings; supports optional persistence so a service restart resumes with a warm cache; offers several eviction policies you can match to your workload; and replicates when you outgrow one instance. Its core executes commands on a single thread — with I/O handled increasingly in parallel in modern versions — which for object-cache traffic is nowhere near the bottleneck.
The practical advantage in hosting is ecosystem gravity: WordPress's Redis object-cache plugins are mature and widely deployed, cPanel platforms provision it cleanly, and the same instance can later back a queue or session store without new infrastructure.
Memcached: one job, done multithreaded
Memcached is deliberately smaller: strings in, strings out, LRU eviction, no persistence, no replication in the core. In exchange it is multithreaded from the ground up, so a busy instance spreads pure get/set across every core it is given, and its slab allocator keeps per-entry memory overhead lean.
Those properties matter at scales hosting rarely reaches — enormous flat caches with brutal request rates. At the scale of a WordPress site or a typical application server, nothing in that list is a margin you will measure; a restart emptying the cache, however, is a behaviour you will.
Deciding, and proving it worked
Decide on operations, not microbenchmarks: does your platform provision it in one click, does your framework's best plugin target it, do you want the cache to survive restarts? In hosting terms those questions all point the same way, which is why Redis over a Unix socket is our default provision.
Then verify with numbers: query count per request before and after (Query Monitor makes this trivial in WordPress), admin TTFB, and the cache hit ratio once warm. A healthy object cache turns dozens of queries into a handful — visible in a histogram the first day it is on.
Redis, provisioned properly, on our platform
Object caching fails most often at the plumbing: TCP where a Unix socket should be, shared instances without isolation, or no provision at all so the plugin silently falls back to the database. We provision Redis per account, socket-connected, sized for the plan.
Paired with LiteSpeed's page cache the two layers cover the whole request spectrum — anonymous pages served before PHP wakes, and the logged-in traffic that must run PHP finding its data already in memory. That pairing, not either layer alone, is what a fast dynamic site is made of.
- Redis available on hosting plans, connected over a local socket
- Works alongside LSCache — page cache for visitors, object cache for logged-in work
- Persistence means restarts do not stampede your database
- Query counts you can verify before and after, per request
Why HostingFast
Standard on every plan
The admin gets fast
Object caching attacks the traffic page caches cannot: wp-admin, logged-in users, carts. The database stops answering the same question twice.
Restart without a stampede
Redis persistence resumes warm, so a deploy or reboot does not funnel every request back to MySQL at once.
Room to grow into
The cache you install today can back sessions, queues and rate limiting tomorrow — one service, no new moving parts.
Quick Start
From order to online
- 1
Baseline your query count
Install Query Monitor and note queries per request on an admin page and a logged-in front-end page. That is the number this change exists to cut.
- 2
Enable Redis and connect the plugin
Provision from the panel, connect over the local socket, and confirm the plugin reports the cache as active rather than silently falling back.
- 3
Re-measure and watch the hit ratio
Queries per request should fall by an order of magnitude once warm. Track the hit ratio for a week; a low one usually means something is flushing the cache.
Built In
Loaded onto every plan
- Object cache provisioned by the platform, not improvised over TCP to somewhere distant
- Unix socket connection where possible — the network hop is the whole cost at this speed
- Plugin verified active, because a misconfigured object cache fails silently to the database
- Eviction policy set deliberately, with memory sized to your working set
- Persistence on if you value warm restarts — the default worth checking, not assuming
- Query count per request measured before and after, so the win is a number, not a vibe
Frequently Asked
What people ask us most often
Which is actually faster, Redis or Memcached?
For object-cache traffic, neither in any way you will measure: both answer in well under a millisecond over a local socket, and the network hop dominates the software either way. Memcached's multithreading pulls ahead only at request rates far beyond a hosted application. Choose on operational behaviour, not on speed folklore.
Does Redis persistence matter if it's only a cache?
More than it sounds. Without persistence, every restart — deploys, reboots, updates — empties the cache and stampedes your database with cold-cache queries at your busiest moment, since restarts correlate with change. Resuming warm turns that cliff into a non-event. It is an operational feature wearing a storage feature's name.
Which should a WordPress site use?
Redis, on ecosystem grounds: the object-cache plugins are mature, hosting integration is standard, and persistence suits the restart patterns of managed platforms. Memcached works — the drop-in exists and functions — but the tooling gravity is with Redis, and in operations you want the well-trodden path.
Is an object cache the same as a page cache?
No, and the difference decides what each can fix. A page cache stores finished HTML and serves anonymous visitors without running PHP. An object cache stores data fragments inside PHP and accelerates the requests that must run — logged-in users, admin, checkout. Fast sites run both; they cover opposite halves of the traffic.
Can Redis and Memcached run side by side?
Technically yes — nothing conflicts — but one application should talk to one object cache, and splitting workloads across both buys complexity without a measurable return at hosting scale. The realistic reason to run both is two applications with different requirements sharing a server.
Keep reading
WordPress hosting
Redis object caching alongside LSCache — both halves of the traffic covered.
VPS hosting
Root access for your own Redis configuration, eviction policy and all.
Server cache vs plugin cache
The page-cache half of the story, and why its position in the stack matters.
Hosting glossary
Object cache, hit ratio, eviction, TTL — the vocabulary, defined plainly.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Cut your query count by an order of magnitude
Redis provisioned over a local socket, LiteSpeed in front, and a query counter to prove the difference — measure it inside the 30-day window.
View WordPress hosting plans