Drupal with Memcached: cache setup and implementation help

When a Drupal Memcached cache layer is the right choice

Memcached is worth planning for when a busy Drupal site runs on several web nodes and the database is carrying cache reads and writes that could be served from memory. Memcached holds volatile key-value cache data only: entries live in RAM, are evicted under memory pressure, and disappear when the service restarts. Drupal does not reach Memcached through core alone. A contributed cache backend module, such as the Memcache API and Integration project, must be installed, configured and kept compatible with your Drupal release, so confirm the module and version pairing for your Drupal version before you commit to a design. No sizing or benchmark figures are given here, so measure your own cache table growth and database load before deciding.

The choice is less about raw speed than about your team and your services. If your organization already runs Redis or Valkey well, with monitoring, backups policy and an operator who knows it, adding a second cache technology may cost more than it saves, and a single Redis or Valkey service can cover cache, locks, flood control and queues. Memcached is more often chosen when a team wants a deliberately simple cache tier with no persistence to manage, or when Redis is not available in the environment. Ask your team three questions: who will operate the service, whether an existing Redis or Valkey deployment is already supported, and how the site behaves if the whole cache tier restarts and every page is rebuilt from the database.

Memcached or Redis for Drupal cache storage

This table compares Memcached and Redis or Valkey on the decisions that shape a Drupal cache layer: data types, persistence, eviction, pool layout and team skills. Read each row against your own traffic, hosting standards and module choices, and confirm current backend support on Drupal.org before you commit.

Decision	Memcached	Redis or Valkey
Cache bin storage	Suited to plain key-value cache entries, which is the bulk of Drupal's render and data cache	Handles cache entries and also supports richer structures if a contributed module needs them
Lock, flood and queue storage	Usually needs a dedicated backend or stays in the database, so confirm the Memcache module covers each service you plan to move	Commonly used for locks, flood control and queues through contributed backends, so confirm module support and version compatibility on Drupal.org
Persistence	Memory only, so a restart empties the cache and the site rebuilds it under load	Can persist to disk, which can shorten warm-up after a restart, but persistence still needs sizing and backup decisions
Eviction behavior	Evicts least recently used items when memory is full, which suits pure cache data	Eviction policy is configurable, and a policy that evicts keys Drupal expects to persist can cause hard-to-trace errors
Multi-server pool layout	Strong fit for a pool of cache nodes where Drupal hashes keys across servers and losing one node only loses its share	Clustered or replicated setups add operational weight, so decide whether you need high availability or simply a shared cache
Operational skills	Simpler service with fewer moving parts, which suits teams that already run Memcached or want minimal administration	Broader ecosystem and tooling, which suits teams already running Redis or Valkey for other applications
Existing platform standards	Choose when your standards already include Memcached for session or cache services	Choose when your standards already include Redis or Valkey, so one service is patched, monitored and backed up for every application
What stays in the database	Confirm which bins, sessions and locks remain on MySQL, MariaDB or PostgreSQL in your configuration	Confirm the same split, since moving only some services is common and must be verified in configuration

What still lives in the database when Memcached holds the cache

Moving cache bins to Memcached does not move Drupal's content, configuration, users, file metadata, or other persistent data. Those stay in the database, which the system requirements list as MariaDB, MySQL, PostgreSQL or SQLite. The cache backend only changes where cached copies of rendered output, data and similar entries are read from and written to. If the site is down when Memcached is down, or Memcached is cleared, the authoritative data is still in the database and Drupal rebuilds the cache from it. Plan backups, restores and database high availability as if Memcached did not exist, because it does not hold anything you can restore from.

Before the cutover, list every cache bin and every non-cache service Drupal uses, then confirm which of them the Memcached module can take over in your version. Lock, flood and queue behavior is the area most often misunderstood. Locks and flood counters depend on the storage a module provides for them, and some Memcached integrations keep only certain bins in Memcached while others stay in the database. Confirm the exact bin and lock behavior in the module documentation for your Drupal version before you assume anything moves. Check the settings.php bin assignments and the lock and flood service definitions in your build, and record which tables still receive writes during a normal page load.

Expect some database load to remain after the change, and test for it rather than guess. Queue items, sessions, watchdog or logging entries, search indexes, and the cron state are typically stored in the database unless you configure a different backend for them. Treat each of these as a decision to document: keep it in the database, move it to another backend with its own availability and eviction rules, or accept it as a known write path. Ask your partner or internal team to produce a list of tables with write activity under representative traffic, so that database sizing, backup scope and recovery steps match what the site actually does.

How to set up a Memcached pool for Drupal

This sequence takes a Drupal site from a database-backed cache to a Memcached pool, with each step closing on a check that proves the change works. It also leaves a documented rollback path so the team can return to the database cache if the pool misbehaves.

Confirm Drupal and PHP versions
Check the Drupal core version in use and compare it with the PHP requirements on Drupal.org. Drupal 10 requires PHP 8.1 or later, Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later, so the target version decides the PHP runtime you must provide. Confirm the running version with drush status and php -v on every web node. Done means the Drupal and PHP versions on each node match the requirements for the planned release, and the team has written them down.
Select and install the cache module and extension
Choose the contributed Memcache cache module that matches your Drupal core version, then install the PHP Memcached extension on every web node that will serve Drupal. Your Drupal and PHP versions limit which module releases are compatible, so check each project page before you install. Confirm the module installs cleanly with Composer and that php -m lists the memcached extension on each node. Done means every web node loads the extension and the module enables without errors on a staging copy.
Deploy Memcached nodes on a private network
Install Memcached on dedicated nodes or containers inside the same private network as the web servers, and bind the service to a private interface only. Block the Memcached port at the host firewall and security group level so no public address or untrusted subnet can reach it, because Memcached has no authentication in its default setup. Confirm from an external host that the port does not respond and from a web node that it does. Done means the port is reachable only from approved application addresses.
Configure cache bins and the server list
In settings.php, set the cache backend class for the bins you want in Memcached and list every pool node with its address and port. Keep the configuration in version control and deploy it through the same release process as code, so every node uses an identical server list. Confirm the configuration with a PHP syntax check and a Drush command that reads the active cache backend for each bin. Done means each intended bin reports the Memcache backend and every node reads the same server list.
Decide which bins stay on the database
Review each cache bin and the lock, flood and queue storage before moving anything. Keep bins that must survive a Memcached restart or that need transactional guarantees on the database, and move only bins that can be rebuilt. Record the decision for each bin in the runbook so the team knows what a pool outage will affect. Confirm the list with the site owner and check that no bin depends on data that exists only in Memcached. Done means every bin has a documented location and an owner.
Rebuild caches and verify hit behavior
Run drush cache:rebuild on staging, then exercise representative anonymous and authenticated pages. Use Memcached statistics such as stats output from each node to confirm that get hits rise and that set operations land on the expected nodes. Check that Drupal pages render correctly and that no cache errors appear in the Drupal logs. Done means the pool records hits after warm-up and the site shows no cache-related errors.
Test failover and pool loss behavior
Stop one Memcached node on staging and load the same pages. Observe how keys are distributed and whether requests slow down or fail, then confirm the site degrades to a cold cache rather than returning errors. Repeat the test with all nodes stopped to confirm the behavior when the pool is unavailable. Record the observed results against the expectations the team set earlier. Done means the failure behavior is written down and accepted by the owner before production.
Document the rollback path
Write a runbook that reverts the settings.php cache backend lines to the database backend, redeploys, and runs a cache rebuild. Include the command to restore the previous configuration, the owner who can approve the rollback, and the signs that trigger it. Rehearse the rollback on staging and confirm the site serves pages from the database cache afterward. Done means a tested rollback procedure exists and the team can execute it without the original author.

Single server or multi-server Memcached pool, by environment

A single Memcached node is usually enough for development and staging, where the goal is to exercise the same cache backend code path as production rather than to handle real traffic. With one node there is no key distribution decision to make: every cache bin writes to the same instance, and the Drupal cache configuration points at one host and port. The main risk is that developers assume caching behavior they never tested, so the environment should match production's cache backend, key prefix and cache bin mapping even though its memory is much smaller.

Server count: one Memcached instance, with the same major version your production pool will run.
Key distribution: none. All bins, including cache_render and cache_dynamic_page_cache, resolve to the single node.
Lost node behavior: the whole cache is empty after a restart. Drupal rebuilds entries on demand, so the site stays up but slower until the cache refills.
Memory: set it from the staging traffic you actually replay, not from production figures copied across. Confirm the sizing with your own measurements.
Go-live checks: confirm that a cache clear and a restart of the Memcached process do not produce errors in the Drupal logs.

Before you rely on this environment, confirm that a deploy from staging behaves the same way it will in production, including the cache warm-up period.

Security and operational risks of a Memcached cache layer

A Memcached cache layer is fast because it holds data in memory with little built-in protection, so the network, the data it holds and the way it is restarted all need deliberate design. The cards below cover the checks a Drupal team should complete with its Memcached vendor documentation and its own environment before the cache goes into production.

Network exposure of the port

Memcached listens on a TCP port that Drupal web servers use directly, and it is not designed to be reachable from untrusted networks. Confirm that the port is bound only to private interfaces, that host firewalls and security groups allow it only from web and worker nodes, and that no load balancer or container port mapping publishes it. Test the rule from outside the cluster or subnet, not just from inside the application network.

Authentication and encryption options

Confirm with the Memcached vendor documentation which authentication and transport encryption features the version you plan to run supports, and whether Drupal's Memcache module and PHP client can use them. Do not assume either exists by default. If the version lacks these options, record the compensating controls, such as private networking, host isolation and tight firewall rules, and document them as accepted risk.

Sensitive data in cached entries

Drupal stores rendered output, render arrays and some entity data in cache bins, and those can include personal data, tokens or account details if a bin is misconfigured. Review which cache bins are routed to Memcached, exclude bins that hold session-like or personal data where possible, and set short lifetimes for anything user-specific. Ask your security team to decide whether cache contents fall within your data classification and retention rules.

Flush and restart effects

A cache flush or a Memcached restart empties memory, so anonymous pages, entity caches and render caches must be rebuilt by the next requests. Depending on where sessions and locks live, users may also lose sessions or see forced logouts. Plan flushes as scheduled changes, coordinate them with deployments, and test how your login flow and cold-cache performance behave before the first production change.

Memory and eviction monitoring

Memcached evicts the least recently used items when memory is full, which is normal for a cache but can hide undersized pools. Track memory use, eviction counts, hit ratio and connection counts per server, and set alerts on sustained eviction growth. Compare these figures with the sizing you chose, and confirm which metrics your Memcached version exposes through its stats interface and your monitoring tool.

Patching the Memcached service

Memcached is a separate service from Drupal, so it has its own vendor advisories, package updates and restart schedule. Assign an owner for watching security notices for the exact Memcached version, and define how quickly patches are tested on a staging pool and rolled out across servers. Because a restart clears the cache, plan rolling restarts one node at a time so the pool keeps serving requests during patching.

Questions buyers ask before choosing Memcached for Drupal

What does a Memcached setup for Drupal cost?

The cost depends on the written scope, not on a list price, because DeployOpen does not publish one. Expect two kinds of spend: one-time work to configure Drupal's cache bins, test cache behavior and document the pool, and recurring work to patch, monitor and tune the Memcached servers. Ask for a quote that lists which bins move to Memcached, how many servers and pools are in scope, whether the environments are shared with an existing Redis service, and how much testing is included. Infrastructure you already run, such as virtual machines or container hosts, is a separate line item from the labor.

What makes the effort larger or smaller on a Drupal site?

Effort rises with the number of cache bins you move, the number of web nodes that share the pool, and whether you already run Redis or Valkey for other purposes. A single-server site with two or three bins is a small change. A multi-server estate with custom cache bins, render cache tuning and load testing is a larger one. Testing scope matters as much as configuration: you need to confirm that cache tags invalidate correctly, that eviction does not remove data the site expects to keep, and that failover behaves as planned. Ask the partner to name each of these factors in the quote.

Can our internal team set up Memcached for Drupal themselves?

Yes, if your team already operates Drupal in production and has someone who can run Memcached servers, configure network access and read cache behavior under load. The Drupal side is mostly settings and a Memcache module, but the operational work is where teams get stuck: sizing memory, handling server restarts that empty the cache, and planning what happens when a node drops out of the pool. Many teams split the work, with their own staff owning the servers and an outside specialist reviewing the Drupal configuration and tests. Decide which parts you own before you request a quote.

How long does a Memcached rollout take for our environment?

No general duration applies, because the timeline depends on your environment and on the scope agreed in writing. The main variables are how many environments need the change (development, staging and production), how quickly your team can provision servers and open network paths, and how much load testing your change board requires. A single-site rollout with existing servers moves faster than a multi-server pool that needs new hosts, security reviews and a maintenance window. Ask for a schedule that lists each gate, including who approves network changes and which environment is used for proof testing.

What do we need to provide before the work starts?

The work needs a few concrete things from your side:

Access to the Drupal codebase, a non-production environment that mirrors production as closely as possible, and deployment pipelines
Hosts or containers for the Memcached servers, with network paths from every web node and firewall rules approved by your network team
Monitoring access so that cache hit rates, memory use and connection errors can be checked before and after the change
A named contact who can approve changes to production and schedule a maintenance window if one is needed

Confirm these items against your own change process before work begins, since approval steps differ between regulated and unregulated organizations.

Can Memcached hold all of Drupal's cache data, including the database?

No. Memcached is a good store for cache entries that can be rebuilt from the database if they disappear, such as render and data caches. It is not a database. Content, configuration, users, sessions in many setups, and anything Drupal must not lose stays in the database. Locks, queues and flood control are a separate question: Drupal's cache backend handles cache bins, but queue and lock behavior depends on the modules and the backend you choose. Confirm with the Memcache module documentation which bins it supports and which must remain on the database, and test the behavior you rely on.

How does Memcached compare with Redis for locks and queues?

Redis offers persistence options, richer data structures and more built-in tooling for queues and locks, which is why many Drupal teams choose it for those jobs. Memcached is a simpler key-value cache with no persistence, so anything stored there can be evicted or lost on restart. For locks and queues that must survive a restart or must not be lost, Redis or the database is usually the safer choice, and Memcached is best kept for disposable cache data. Your decision should rest on which Drupal features you run, your team's operating experience and your recovery requirements. The sibling topic on Redis or Valkey covers the alternative in more detail.

Does DeployOpen support the Memcached service after launch?

Ongoing support, upgrades and continuous testing are available as retainers, separate from the initial fixed-scope implementation. A retainer can cover patching the Memcached servers, reviewing cache hit rates after content or traffic changes, and retesting after Drupal core or module updates. Ask for the support scope in writing, including response expectations and which systems it covers, and do not assume any service level unless it appears in your signed agreement.

What to confirm about Memcached in your Drupal environment

Memcached sits between Drupal and your servers, so a mismatch in any layer can break caching for every visitor. The items below are the checks to run before you choose a module and build the cache tier. No version figures are given on this page, so confirm each one against the module's project page and your own environment.

Module compatibility with Drupal and PHP

Confirm that the Memcache module you select supports your Drupal core version and the PHP version your web servers run. Drupal sets its own minimum PHP version for each major release, so the core upgrade path and the cache module can constrain each other. Check the module's project page for the core branches it supports and the release it recommends, and record that pairing in your upgrade plan before you build.

Memcached server and PHP extension versions

Drupal reaches Memcached through a PHP extension, and the extension and the Memcached server each have their own version lines. Confirm which extension your PHP build provides, which Memcached server release your platform can run, and whether the pair has been tested together. Pin both versions in your build so a routine OS update does not change the cache layer underneath production.

Supported cache bins, locks and queues

Not every Drupal storage role moves to Memcached in the same way. Ask the module maintainers which cache bins it serves, whether it handles the lock backend and the queue, and how it behaves when Memcached evicts items. Lock and queue data usually needs to survive longer than a cache entry, so confirm that the module keeps those roles in the database or another store where it says it does.

Network path from your hosting platform

Web nodes must reach every Memcached instance on the port you configure, and that path has to survive your firewall rules, security groups, container networking and load balancers. Confirm that your hosting platform allows traffic between the web tier and the cache tier, and that no managed service layer blocks it. Also confirm whether the cache nodes can sit in a private subnet without public exposure.

Failover and key distribution behavior

Your client library decides how keys map to servers and what happens when one node is unavailable. Ask whether the library uses consistent hashing, how it handles a node that drops out of a pool, and whether a failed node causes timeouts for every request. Test a node failure in staging, since a poorly configured pool can slow Drupal more than a cache miss would.

Security advisories for the module

Check the Drupal.org security coverage for the cache module and its dependencies before you approve it. The Drupal Security Team publishes advisories for contributed projects with CVE identifiers and risk scores, and fixes arrive in scheduled security release windows. Subscribe to the project's advisories and confirm how your team will apply a security release to the cache tier as well as to Drupal itself.

How DeployOpen scopes and delivers a Drupal Memcached cache layer

DeployOpen plans, builds, documents and supports Memcached cache layers for Drupal inside your own infrastructure, from a written scope agreed before work starts. Each engagement is sized to your server topology, cache needs and the database work that must stay in place.

How we scope

We confirm your Drupal version, PHP version and web server layout before agreeing what Memcached work is in scope.
The written scope lists the Memcached servers, the pool design, the bins moved off the database and the environments covered.
We record which data stays in the database, such as persistent entities and content, so the boundary is agreed up front.
Engagements are fixed-scope, and ongoing support is available as a retainer once the cache layer is live.

How we build

We configure the Drupal cache backend in settings for your environments, with the bins and fallbacks named in code review.
We size and place Memcached instances and network access rules inside your cloud accounts, data centers or private networks.
We test cache hits, invalidation behavior and failure handling, including what happens when a Memcached node is unavailable.
Changes are delivered through version control and your deployment pipeline so the configuration can be reviewed and repeated.

How we hand over

You receive a runbook covering configuration keys, server addresses, restart order and how to flush specific bins safely.
Architecture notes explain why each bin lives in Memcached or the database, so future module changes are assessed correctly.
We walk your platform and operations staff through monitoring signals, expected hit ratios and the escalation path.
Verification results and the agreed acceptance criteria are documented so your auditors and team can review them later.

How we support

Support retainers cover Memcached and Drupal cache configuration after launch, including reviews before major Drupal upgrades.
We help plan updates to Memcached, the PHP Memcached extension and Drupal core within the agreed support arrangement.
Periodic checks cover capacity, eviction behavior and whether new contributed modules write cache data in unexpected places.
Please confirm with your team which support hours, response paths and maintenance windows apply to your environment.

Drupal with Memcached