Using Redis or Memcache for session datafor Drupal 11 , 10 , 9 , and 8

Home » Performance Optimization » Using Redis or Memcache for session data
Last updated :  
11.x , 10.x , 9.x , 8.x

Drupal's default session storage lives in the database — a real, if usually small, write on nearly every authenticated request, competing for the exact same database connections as everything else your site does. Moving session storage to Redis or Memcache — in-memory stores built specifically for fast key-value access — takes that load off the database entirely, the same "different tool for a different job" principle from the Cache Backends section applied to sessions specifically.

What you'll learn in this lesson

  • Why sessions specifically benefit from in-memory storage
  • Configuring an alternate session handler
  • What's lost by moving off the database, and why it's usually an acceptable trade

Why sessions are a good fit for this

Session data is small, accessed extremely frequently (every authenticated request), and doesn't need the durability guarantees a database provides — losing an active session on a cache-store restart means that user just logs in again, not a genuine data-loss event the way losing a saved node would be. That's exactly the profile of data in-memory stores excel at.

Configuring Redis-backed sessions

// settings.php — requires the contrib redis module already configured
// for caching (from the Cache Backends section) as a prerequisite.
$settings['session_handler'] = 'redis';
$settings['redis.connection']['host'] = '127.0.0.1';
$settings['redis.connection']['port'] = 6379;
This is a prerequisite-dependent setting, not a standalone one. Session storage configuration assumes you've already got Redis (or Memcache) running and connected for general caching, from the Cache Backends lesson earlier in this tutorial. Don't add session storage as your first-ever Redis integration on a site — get basic cache-backend caching working and verified first, then extend it to sessions.

What's actually lost moving off the database

Database-backed sessions survive a database backup/restore automatically, as part of the same backup process covering the rest of your site's data. Redis-backed sessions typically don't get included in that same backup unless you specifically configure Redis persistence — meaning a Redis restart without persistence configured logs out every currently-active session at once. For most sites, "everyone gets logged out occasionally" is an acceptable trade for the performance win; for a site with genuinely critical long-lived sessions, configure Redis persistence (RDB or AOF) explicitly rather than accepting the default in-memory-only behavior.

Quick check: after moving sessions to Redis without configuring Redis persistence, a server restart logs out every active user. Is this a bug, or expected behavior given the configuration? If you said expected — in-memory storage without persistence doesn't survive a restart by design — you've understood the real trade-off this lesson is asking you to make deliberately, not accidentally.

Key takeaways

  • Sessions are small, frequently-accessed, and tolerant of occasional loss — exactly the profile in-memory storage suits well.
  • Session storage configuration builds on an existing Redis/Memcache cache-backend setup, not a standalone integration.
  • Without explicit persistence configuration, a Redis restart logs out every active session — a real trade-off to make deliberately.
  • Configure Redis persistence (RDB/AOF) explicitly if session survival across restarts genuinely matters for your site.

Coming up next

You've moved where sessions live. Next, we reduce how often session writes happen at all, specifically for anonymous visitors who make up the bulk of traffic on most sites.