Valkey, Redis or Varnish? Caching for Magento 2 Explained

For a Magento 2 store, the answer to "Redis or Varnish?" is usually both, or more precisely Varnish plus Valkey. Varnish is a full-page cache: it sits in front of the web server and returns complete pages without running PHP, which is what makes category and product pages fast under load. Valkey, a Redis-compatible in-memory store, holds Magento's application cache and customer sessions, so the application itself responds faster and sessions survive across several web servers.

Adobe recommends Varnish as the full-page cache for production, and its latest system requirements list Valkey as the supported cache and session store, with Redis no longer listed for the newest patch releases. Our original version of this article dated from 2021 and compared Redis and Varnish as alternatives; this refresh explains how the pieces fit together today.

The three caching layers in Magento 2

Without any of these, Magento stores its cache and sessions on the file system and builds every page in PHP. That works for development but becomes slow and fragile with real traffic, and impossible to share across more than one web server.

The three layers also fail differently. If Varnish goes down, pages are still built by PHP, only more slowly. If the cache store goes down, Magento rebuilds cache entries on demand, again more slowly. If the session store goes down, customers lose their baskets and sign-ins, which is the most visible failure of the three. That is why sessions deserve the most care in configuration and monitoring.

Varnish: the full-page cache

Varnish is a reverse proxy that stores rendered pages and serves them directly. When a visitor requests a cached category page, Varnish returns it in milliseconds without touching PHP or the database. Magento integrates with it closely: it generates a Varnish configuration file, sends cache tags with each page and purges the right pages when products, prices or content change.

• Configure Magento to use Varnish in the admin under the full-page cache settings, then export the generated configuration file.
• Use a supported Varnish version for your Magento release; Adobe's current requirements list Varnish 8.
• Put HTTPS termination in front of Varnish, for example with nginx, because Varnish itself does not handle TLS.
• Keep personalised content out of cached pages using Magento's private content mechanism, which loads customer-specific blocks separately.

Adobe's Varnish configuration guide describes the set-up in detail.

Regenerate the Varnish configuration file after Magento upgrades and when you change the backend host or port. An outdated file is a common reason cache purges stop working silently: products update in the admin, but visitors keep seeing the old price until the cache entry expires.

Warm the cache after deployments by requesting your most important pages, so the first real visitors after a release do not all wait for pages to be built at once.

Valkey and Redis: application cache and sessions

Redis has long been the standard choice for Magento's application cache and sessions. In 2024 Redis changed its licence, and the open-source community created Valkey, a fork that remains Redis-compatible. Adobe's documentation now includes a Valkey configuration guide, and its system requirements list Valkey for the latest releases and patches, with Redis marked as not supported in the newest patch lines.

In practice, Valkey works the same way Redis did for Magento: it stores cache entries and sessions in memory, supports tag-based cache cleaning and can save data to disk for persistence.

# Application cache in Valkey (Redis-compatible backend options), database 0
bin/magento setup:config:set --cache-backend=redis \
  --cache-backend-redis-server=127.0.0.1 --cache-backend-redis-db=0

# Sessions in a separate database
bin/magento setup:config:set --session-save=redis \
  --session-save-redis-host=127.0.0.1 --session-save-redis-db=2

Check the configuration guide for your exact Magento version before applying settings; option names and recommended values can change between releases. After changing cache settings, flush the cache with bin/magento cache:flush and watch the logs for connection errors.

Valkey can also store the full-page cache when Varnish is not available, using a separate database. That is better than the file system, but Varnish remains faster for serving whole pages because it answers before the request reaches PHP at all.

Why you usually need both

Varnish and Valkey solve different problems, so one does not replace the other.

• Varnish speeds up pages that can be shared between visitors: home, categories, products and CMS pages.
• Valkey speeds up everything that still runs in PHP: the basket, checkout, account pages, the admin and uncached requests.
• Sessions in Valkey allow several web servers to share customer sessions, which is essential for scaling.

A store with Varnish but file-based caches will still feel slow in checkout and admin. A store with Valkey but no full-page cache will struggle when a campaign sends thousands of visitors to the same category at once.

A content delivery network adds a fourth layer in front of everything else, serving images, scripts and styles from locations near your customers. It reduces bandwidth and load on your servers, but it does not replace Varnish for dynamic HTML pages.

Configuration best practices

Adobe's cache guides recommend separating the workloads, because they behave differently.

1. Use separate instances or databases for sessions, the application cache and any page cache stored in Valkey.
2. Enable persistence for sessions with snapshots or an append-only file, so customers do not lose baskets when the service restarts. Caches can usually run without persistence.
3. Set memory limits and an eviction policy for cache instances, so the cache cannot exhaust server memory.
4. Enable lazy freeing options such as lazyfree-lazy-eviction, which Adobe's Valkey guide recommends to reduce blocking when large keys are removed.
5. Keep the services close to the web servers on a private network, protect them with authentication, and never expose them to the internet.

Our guide to Magento hosting and server requirements covers where these services fit in a typical server layout.

Measuring the effect

Caching changes should be measured, not assumed. Record a baseline before making changes, then compare.

• Varnish hit rate: the share of requests served from cache; low rates often point to cookies or headers preventing caching.
• Time to first byte for cached and uncached pages, measured from more than one location.
• PHP-FPM load during busy periods, such as campaign launches and sale days.
• Valkey memory use and evictions, which show whether the cache is large enough for your catalogue.
• Core Web Vitals for real visitors, which reflect the overall experience on their own devices and connections.

Our article on Core Web Vitals for online stores explains the visitor-facing measures, and our guide to speeding up a Magento store covers other optimisations.

Common caching problems

Caching for logged-in and B2B customers

Full-page caching works best for anonymous visitors who all see the same page. Stores where most customers log in, such as B2B portals with customer-specific prices and catalogues, get less benefit from Varnish, because many pages vary by customer group or company.

• Cache by customer group where prices and catalogues differ only by group, which Magento supports through its cache context.
• Use private content blocks for small personalised elements such as the mini-cart and greeting, so the rest of the page stays cacheable.
• Invest in the application cache and database for pages that cannot be cached, because those requests always reach PHP.
• Profile slow uncached pages such as quick order, requisition lists and account dashboards.
• Plan capacity on uncached traffic, not on headline visitor numbers, when sizing servers.

For these stores, Valkey's role grows. A fast, well-sized application cache and session store makes the biggest difference to everyday performance, while Varnish still helps with public catalogue and content pages. Our guide to B2B e-commerce portals covers the business side of these features.

Moving from Redis to Valkey

Because Valkey is Redis-compatible, moving an existing store is usually straightforward. Install Valkey at a supported version, point Magento's cache and session settings at it, and test on staging. Plan the switch for a quiet period, as sessions stored in the old service will not carry over unless you migrate them, so some customers may need to sign in again.

Combine the move with an upgrade to a supported Magento patch release where possible, since the requirements and the cache service are designed to go together.

After the switch, watch error logs, session behaviour and cache hit rates for a few days. If anything looks wrong, the old service can be brought back quickly while you investigate, because the configuration change is small and easy to reverse.

Frequently asked questions

Want your Magento caching set up and tuned properly? Talk to our team, or see our Magento development services.