What's new
Toggle Nav
My Cart
Magento glossary

What is Magento Redis Cache ?

Magento Redis Cache means running Redis, an in-memory key-value store, as the backend for Magento’s cache types (config, layout, block_html, collections, reflection and the rest), for PHP sessions, and, if you do not run Varnish, for the full page cache too. I set it up on every production store I work on, because the default file cache in var/cache slows down under concurrent traffic and cannot be shared between servers. The usual layout is three logical databases: db 0 for cache, db 1 for full page cache, db 2 for 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

Magento talks to Redis through its own cache and session drivers, configured in app/etc/env.php. This is how I wire it up, from install to keeping an eye on it.

  1. 01

    Install Redis on the same network as Magento

    On a single server I install it with apt install redis-server (Ubuntu or Debian) or the distro package on RHEL-based systems. On cloud hosting I use the managed service, such as AWS ElastiCache, GCP Memorystore or Azure Cache for Redis, in the same region and network as the web servers. Keep Redis close to PHP-FPM: one page request can make many cache calls, so network latency adds up quickly.

  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. Magento writes the Redis settings into app/etc/env.php under cache/frontend/default, and every cache type except the full page cache (config, layout, block_html, collections, reflection and so on) now lives in Redis database 0.

  3. 03

    Route page-cache and sessions to separate logical DBs

    I run the same command again with --page-cache=redis --page-cache-redis-db=1 for the full page cache, and --session-save=redis --session-save-redis-host=127.0.0.1 --session-save-redis-db=2 for sessions. Separate databases mean that flushing the cache from the admin or with bin/magento cache:flush leaves sessions alone, so nobody gets logged out or loses a cart.

  4. 04

    Cache entries are tagged, and saves clean by tag

    Magento saves each cache entry with tags, for example CAT_P_42 for product 42 or CAT_C_7 for category 7. When you save a product in the admin, Magento cleans every entry that carries that product’s tags and leaves the rest of the cache alone. The Redis backend keeps a set of keys per tag, so this is a quick lookup. With the file backend the same clean means reading tag files from disk, which gets slow on bigger stores.

  5. 05

    Monitor with redis-cli during peak traffic

    During busy periods I check redis-cli INFO memory for used_memory_human against maxmemory, and redis-cli INFO stats for keyspace_hits, keyspace_misses and evicted_keys. A climbing eviction count usually means Redis is too small for the store. redis-cli MONITOR shows hot keys, but it is expensive, so I only run it for a few seconds. For long-term graphs, New Relic, Datadog and Percona PMM all have Redis dashboards.

When to use

Four situations where Redis is the obvious answer

Redis does not fix every cache problem, but in these four cases I would not run a Magento store without it.

  • Any production Magento store

    The file cache is fine on a laptop or in CI. In production, with many PHP-FPM workers reading and writing var/cache at the same time, it gets slow and turns into a lot of disk I/O. Every production store I take on gets Redis for the default cache and sessions. Magento 2.4 documents Memcached only as a session store, not as a cache backend, so for the cache Redis is the practical choice.

  • Multi-server / horizontally-scaled deploys

    Once there are two or more web servers behind a load balancer, the file cache stops working properly: each server has its own var/cache/ and never sees the other servers’ invalidations. With Redis every web server reads and writes the same cache, so a product save on one server is visible on all of them straight away.

  • Large catalogs and many store views

    Big catalogs mean a lot of cached layout, block_html and collection data, and every extra store view multiplies it. The file cache turns that into a huge number of small files and heavy disk I/O on every tag clean. On stores like this, moving the cache to Redis is often the first change I make, before I touch any code.

  • Replacing old Memcached session setups

    Some stores that came over from Magento 1 still keep sessions in Memcached. It works, but Memcached has no persistence, so a restart logs everyone out and empties every guest cart. I usually move sessions to Redis db 2 with --session-save=redis, so cache and sessions run on one service, and with persistence turned on the sessions survive a Redis restart.

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
Chat on WhatsApp