Chat on WhatsApp
Toggle Nav
My Cart
Magento glossary

What is Magento Redis Cache ?

Magento Redis Cache is the use of Redis, an in-memory key-value store, as Magento’s cache backend (default, page, layout, block_html, collections, reflection), as the session storage backend, and optionally as the full-page-cache backend instead of Varnish. Replacing the file-system cache with Redis typically cuts admin save times and page generation times by 30 – 60%. Three logical databases are conventionally used: db 0 caches, db 1 FPC, db 2 sessions.

Need Redis tuning help? How it works

Written by Kishan Savaliya — Adobe Certified Magento & Hyvä developer, 8 years on platform

How it works

Five steps from install to monitored production

Redis is not a black-box service — Magento talks to it through a documented backend driver. Here is the wiring, end to end.

  1. 01

    Install Redis on the same network as Magento

    On a single-server setup run apt install redis-server (Ubuntu / Debian) or yum install redis (RHEL / Amazon Linux). On managed cloud, provision AWS ElastiCache for Redis, GCP Memorystore, or Azure Cache for Redis in the same VPC / region as the Magento web heads. Latency from Magento PHP-FPM to Redis should stay sub-millisecond — every extra ms hits PDP / PLP request times directly.

  2. 02

    Point Magento's default cache at Redis db 0

    Run bin/magento setup:config:set --cache-backend=redis --cache-backend-redis-server=127.0.0.1 --cache-backend-redis-db=0. This writes the Redis backend into app/etc/env.php under cache/frontend/default and routes the default, layout, block_html, collections, config, and reflection caches into Redis logical database 0.

  3. 03

    Route page-cache and sessions to separate logical DBs

    Repeat the config command with --page-cache=redis --page-cache-redis-db=1 for full-page cache, and --session-save=redis --session-save-redis-host=127.0.0.1 --session-save-redis-db=2 for PHP sessions. Three logical databases — 0 / 1 / 2 — keep cache, FPC, and session invalidations from colliding. Flushing the catalogue cache should never drop a customer’s shopping session.

  4. 04

    Magento writes tagged keys; saves invalidate by tag set

    Every cache write is stored against a tag index (for example CAT_p_42, CAT_c_7, BLOCK_HTML). When a product is saved, Magento computes the affected tag list and Redis atomically deletes every key in those tag sets in one round-trip. That tag-based invalidation is the main reason Redis beats the file-system cache — file cache cannot do atomic multi-key drops without a directory scan.

  5. 05

    Monitor with redis-cli during peak traffic

    Run redis-cli INFO memory to see used_memory_human and maxmemory; redis-cli INFO stats for keyspace_hits / keyspace_misses (target hit ratio > 95%); and redis-cli MONITOR (sample for 60s only — it’s expensive) to spot hot keys during BFCM-class peaks. New Relic, Datadog, and Percona PMM all have first-class Redis dashboards if you want it long-term.

When to use

Four situations where Redis is the obvious answer

Redis isn't the right answer for every cache problem, but in 2026 these four scenarios are unambiguous wins for a Magento store.

  • Any production Magento store

    File-system cache is fine for local dev and CI — it has zero ops cost. In production it falls over the moment two PHP-FPM workers race on the same cache key. Every production Magento store in 2026 should run Redis (or Memcached, but see below) for the default cache backend. The default file backend was never designed for concurrent production workloads.

  • Multi-server / horizontally-scaled deploys

    The moment you put Magento behind a load balancer with two or more web heads, the file cache breaks: each web head has its own var/cache/ directory and they don’t share state. Redis is network-attached shared storage by default — every web head talks to the same Redis cluster, every invalidation is seen instantly across the fleet, and rolling deploys don’t cold-start the cache.

  • Large catalogues — 100k+ SKUs

    Stores with more than 100k SKUs hit the collections cache constantly — every PLP page render computes filtered product collections, every PDP related-product render hits collections. Without Redis those collection queries punch through to MySQL and admin save times balloon into 30s+. With Redis on db 0 the same collection serialises into a hot tag set and admin saves return in 2 – 5s.

  • Replacing legacy Memcached setups

    Memcached was the canonical Magento 1.x cache backend and still works in Magento 2 — but it has no tag-based invalidation, no built-in persistence, and no clustering primitives. Redis matches Memcached on raw speed and adds: tag sets for atomic multi-key drops, optional AOF/RDB persistence, Sentinel for HA, and Redis Cluster for horizontal sharding. There is no reason left to pick Memcached for a new Magento install in 2026.

Common mistakes

Three Redis misconfigs that wreck a Magento store

Every Redis-related Magento outage I've been called in to debug came from one of these three mistakes. Audit your env.php and redis.conf for them today.

  • Sharing one Redis DB across cache, FPC, and sessions

    Pointing the default cache, full-page cache, and session storage at the same Redis logical database (typically db 0) is the single most common Magento Redis misconfig. When the catalogue cache is flushed, the FLUSHDB also kills active shopping sessions and full-page-cache entries simultaneously — every logged-in customer is logged out, every PDP cold-starts at once, and origin server load spikes. Always separate by logical db: 0 for default cache, 1 for FPC, 2 for sessions.

  • Forgetting compress_data on block_html caches

    Magento’s block_html cache stores fully-rendered HTML fragments — header / footer / mini-cart / category navigation. On a store with 50 store views and 10k categories those fragments balloon Redis memory into the multi-GB range. Set compress_data: 1 and compress_threshold: 2048 in the Redis backend options inside env.php. Gzip costs ~1 ms per fragment, saves 60 – 75% memory, and stops Redis hitting maxmemory mid-day.

  • Running Redis without maxmemory + LRU policy

    A stock Redis install has no maxmemory cap and uses maxmemory-policy=noeviction. With Magento writing constantly to it that means Redis grows until the kernel OOM-kills the process — at which point every Magento page goes 500. Always set maxmemory 2gb (or appropriate sizing) and maxmemory-policy allkeys-lru in /etc/redis/redis.conf. With LRU enabled, Redis evicts cold keys gracefully instead of crashing.

Related concepts

Five neighbour concepts most readers want to look at next. Click through for the full deep-dive.

FAQ

Magento Redis Cache — frequently asked questions

  • Redis vs Memcached for Magento — which should I pick?
    Redis, every time, for a new Magento 2 install in 2026. Both backends are roughly comparable on raw single-key throughput, but Redis adds four features Memcached cannot match: (1) tag-based invalidation, which Magento uses heavily for atomic multi-key drops on product / category saves; (2) optional persistence via AOF or RDB, so a Redis restart doesn't cold-start the entire cache; (3) Sentinel for high availability without a separate proxy; (4) Redis Cluster for horizontal sharding past 100 GB. Memcached still ships in Magento and works fine, but there is no scenario where it beats Redis in 2026.
  • Should I use Redis for full-page cache or stick with Varnish?
    Both, if you can. Varnish is faster at serving cached page HTML than Redis because it lives in front of Magento and avoids the PHP boot for cache hits — TTFB for cache-hit pages is typically 20 – 50 ms with Varnish vs 150 – 300 ms with Redis FPC. For high-traffic stores Varnish is the right answer. Redis FPC is a good fallback when you can't run Varnish — for example on shared hosting, on Adobe Commerce Cloud test environments, or when your CDN already does edge caching and Varnish duplicates the work. Don't pick Redis FPC just because it's simpler — measure first.
  • How much Redis memory do I need for a Magento store?
    Rule of thumb: budget around 200 MB of Redis memory per 10,000 SKUs as a starting point, then watch <code>used_memory_human</code> over a full week of normal traffic and round up to the next 512 MB. A 50k-SKU store typically settles around 1 – 1.5 GB; a 250k-SKU store 4 – 6 GB; a 1M-SKU store 12 – 20 GB. Add a 30% headroom for peak season traffic and a 20% safety margin for the <code>maxmemory-policy=allkeys-lru</code> eviction overhead. If you run Redis FPC on the same instance, double the budget — full-page HTML fragments are bulky.
  • Why is my Redis using more memory than the cache should?
    Three usual suspects. First — <code>compress_data</code> is off in <code>env.php</code>; large block_html fragments are stored uncompressed and eat 4 – 6x more memory than they need. Second — cache TTLs are too long or set to 0 (never expire), so cold keys never get evicted; verify with <code>redis-cli --bigkeys</code>. Third — you're sharing one Redis db across cache, FPC, and sessions, so the count is the sum of all three, not just the cache. Run <code>redis-cli INFO keyspace</code> to see per-db key counts, then separate them onto db 0 / 1 / 2 if they collide.
  • Can I cluster Redis with Magento for high availability?
    Yes, two routes. Redis Sentinel gives you primary / replica failover — one primary handles all writes, one or more replicas stand by, and Sentinel promotes a replica if the primary dies. Magento talks to Sentinel and gets routed to the current primary. Simpler to operate, supports the full Magento Redis backend feature set. Redis Cluster gives you horizontal sharding for the rare 100 GB+ cache size case — keys are sharded across multiple primaries. Cluster requires Magento ≥ 2.4.5 and a slightly different Redis backend driver. For 95% of Magento stores, Sentinel is the right answer.
  • Does Hyvä Themes affect Magento Redis usage?
    Slightly — Hyvä reduces total Redis memory used by the <code>block_html</code> cache because Hyvä templates are smaller (less inline JavaScript, no KnockoutJS markup, fewer wrapping divs) so each cached HTML fragment is shorter. Expect a 15 – 25% drop in block_html cache size after a Hyvä migration. The other caches (default, config, layout, collections, FPC, sessions) are unaffected — they're backend-driven and don't care which frontend theme is rendering. Hyvä also has zero impact on session storage, so session-backend sizing stays the same.
Redis audit

Want a Redis audit on your Magento store?

Send your storefront URL — I will run a Redis hit-ratio + memory + key-distribution audit and reply with a written tuning plan, fixed-price quote, and earliest start date. 24-business-hour turnaround.

Get a Redis audit Hire me directly