Home / Use Cases / Session Store

Verdict: Redis or Valkey for sessions. Memcached for sessions is a 2010-era pattern that 2026 architectures should avoid.

Should You Use Redis or Memcached for Sessions? (2026)

Sessions look like a cache workload but they are not. The four structural reasons why Memcached for sessions is a footgun.

The four reasons sessions need Redis or Valkey, not Memcached

Persistence

Memcached process restart wipes all data. No persistence, by design. In a session store, that means every active user gets logged out when the cache restarts: deployments, OOM kills, hardware failures. Redis and Valkey both offer RDB snapshots and AOF write-ahead logs. A Redis/Valkey instance restart reloads the session store from disk within seconds.

Replication

A single Memcached node is a single point of session loss. No built-in replication: if the node fails, the session data is gone. Redis master-replica replication keeps a copy on at least one replica at all times. Failover can be automatic with Redis Sentinel or Redis Cluster. Valkey implements the same replication model.

TTL-aware eviction

Memcached uses LRU only. Under memory pressure, it evicts the least recently used items, which may include active sessions (sessions for users who logged in 2 hours ago but have been idle for 30 minutes). Redis and Valkey offer volatile-lru (LRU only on keys with TTL set) and volatile-ttl (evict keys nearest expiry first), which are more appropriate for session stores where you want to preserve active sessions.

Atomic operations

Session updates are often read-modify-write patterns (increment a counter, append to a list, update one field of a session object). Memcached's CAS (Check-And-Set) for atomic updates is awkward and error-prone. Redis hash commands (HSET, HINCRBY, HDEL) and atomic operations (MULTI/EXEC transactions, Lua scripts) handle this cleanly. Valkey is equivalent.

Code samples: session in Redis vs Memcached

Redis (Python, redis-py)

import redis

r = redis.Redis(host='localhost', port=6379)

# Create session
session_id = "sess:abc123"
r.hset(session_id, mapping={
    "user_id": "42",
    "email": "ada@example.com",
    "role": "admin",
})
r.expire(session_id, 3600)  # 1-hour TTL

# Read session
session = r.hgetall(session_id)

# Extend TTL on access (sliding window)
r.expire(session_id, 3600)

# Update one field atomically
r.hset(session_id, "last_seen", "2026-05-01T12:00:00Z")

# Destroy session (logout)
r.delete(session_id)

Persistent, replicated, TTL-aware, atomic updates. Session survives restarts.

Memcached (Python, pymemcache) — fragile

import json
from pymemcache.client import base

c = base.Client(('localhost', 11211))

# Create session (must serialize to string)
session_id = "sess:abc123"
session_data = {
    "user_id": "42",
    "email": "ada@example.com",
    "role": "admin",
}
c.set(session_id, json.dumps(session_data), expire=3600)

# Read and deserialize
raw = c.get(session_id)
session = json.loads(raw) if raw else None

# WARNING: TTL does NOT extend on read
# You must re-set with new TTL manually

# WARNING: Update one field = full re-serialize
session["last_seen"] = "2026-05-01T12:00:00Z"
c.set(session_id, json.dumps(session), expire=3600)

# WARNING: restart wipes all sessions

No persistence, no replication, manual serialization, no atomic field updates. Do not use for sessions.

Framework defaults in 2026

Rails 7+

Rails 7 defaults to ActiveSupport::Cache::RedisCacheStore for caching and ActionDispatch::Session::CacheStore backed by Redis for sessions. The Rails guides explicitly note that Memcached for sessions requires additional configuration and is not recommended for production because of the persistence and replication gap. Source: api.rubyonrails.org.

Django 4+

Django supports both django-redis and django-memcached for SESSION_ENGINE. The Django docs note: 'If you're using the database as a session store, you don't need to worry about this. But if you're using cache-based sessions, you should use Redis rather than Memcached.' The practical steer is toward Redis for sessions in all Django production deployments.

Node.js (express-session)

The connect-redis package is the dominant session store for express-session in Node.js. connect-memcached exists but is less maintained and lacks the same replication/persistence guarantees. Most Node.js production session stores default to Redis or a Redis-compatible store (Valkey works with connect-redis).

Redis 8.0: hash field TTL for cleaner sessions

Redis 8.0 (May 2025) introduced hash field TTL: HEXPIRE lets you set per-field expiry on a hash. This is useful for sessions where different fields have different lifetimes (authentication token expires in 15 minutes, session preferences persist for 30 days).

# Redis 8.0: per-field TTL on session hash
HSET user:123 name "Ada" email "ada@x.com" auth_token "tok_abc"

# Email and name persist indefinitely, auth_token expires in 15 min
HEXPIRE user:123 900 FIELDS 1 auth_token

# Preferences hash field persists for 30 days
HEXPIRE user:123 2592000 FIELDS 1 preferences

Note: hash field TTL is Redis 8.0-specific. Valkey 8.1 does not yet support HEXPIRE (in roadmap). Source: redis.io/docs/commands/hexpire

What about Valkey for sessions?

Valkey works equivalently to Redis 7.2 for session storage: persistence (RDB + AOF), master-replica replication, ACLs, native TLS, LFU eviction. Most Redis session clients (connect-redis, redis-py, Jedis) work with Valkey unchanged since it is RESP-compatible. The only gap: hash field TTL (HEXPIRE) is not yet in Valkey 8.1. If your session pattern requires per-field TTL, stay on Redis 8.0. For all other session patterns, Valkey is a drop-in replacement with BSD licensing.

More code samples →Full feature comparison →All use cases →