Deployment
Redis & caching

Redis vs Memcached for Django Caching

Compare Redis and Memcached as the Django cache backend: data structures, persistence, eviction, multi-purpose use for sessions, Celery, and rate limiting, memory efficiency, scaling, and managed options, with a recommendation.

Problem statement

Django ships cache backends for both Redis and Memcached, and both are fast in-memory stores. For pure caching they behave similarly, so the choice usually comes down to what else you need: Redis also serves as a Celery broker, session store, rate-limit counter, and lock service, and it can persist data. Memcached does one thing, very simply. Picking based on your whole stack avoids running two services where one would do, or overloading one instance with conflicting roles.

Two cache backendsDjango cache APIsame codeRediscache + broker + moreMemcachedcache only, simpleChoose byother needs, opsThe cache API is identical; Redis's extra roles are usually what decides.
  1. Choose Redis for most Django projects: one service can cover cache, sessions, Celery broker, rate limiting, and locks, and Django has a built-in Redis backend.
  2. Choose Memcached for a pure, very large, multi-node cache where simplicity and memory efficiency for small values matter, and nothing else needs Redis.
  3. Run separate Redis instances (or databases with care) for cache and Celery so eviction policies do not conflict.
  4. Both are memory-only for caching purposes; never store data you cannot recompute.
  5. Performance is excellent for both; network round trips dominate.

Comparison

Features

Redis supports strings, hashes, lists, sets, sorted sets, streams, TTLs, atomic increments, Lua scripting, pub/sub, and optional persistence (RDB, AOF). Memcached supports key-value strings with TTLs and atomic increments, nothing more. For Django's cache API (get, set, incr, delete_many), both suffice. Redis's extras power features like rate limiting with sliding windows, distributed locks, leaderboards, and Channels layers.

Persistence and eviction

Memcached never persists; a restart empties it. Redis can persist, which matters for sessions and Celery queues but is unnecessary for a pure cache. Both evict when memory is full: Memcached uses LRU per slab class; Redis uses the maxmemory-policy you choose (allkeys-lru for caches, noeviction for broker data).

side by sideRedisMemcachedDjango backendbuilt in (RedisCache)built in (PyMemcacheCache)Data structures✓manystrings onlyPersistence✓optionalnoneOther Django roles✓sessions, Celery, lockscache onlyScaling outreplicas, Cluster✓client-side shardingFor caching alone they are close; Redis does far more beyond cachingdjango-deployment.com
Fewer services usually means fewer outages; Redis often replaces two tools.

Memory and scaling

Memcached is multi-threaded and very memory-efficient for many small values; adding nodes scales capacity through client-side consistent hashing. Redis is mostly single-threaded per instance for commands (with I/O threads in newer versions), and scales with replicas for reads or Redis Cluster for sharding. For typical Django caches of a few gigabytes, one Redis instance is plenty.

Operations

Both are simple to run and widely available as managed services (ElastiCache, Memorystore, Azure Cache, Upstash, Redis Cloud). Redis licensing changed in 2024, and Valkey, a Linux Foundation fork, is now a common open-source drop-in replacement; Django's Redis backend works with it.

which cache backend?What else does the stack need?Celery, sessions, locks tooRedis (or Valkey)separate cache instancepure cache, huge, multi-nodeMemcachedsimple, efficientalready running oneUse what you haveboth work wellThe backend is one settings change; switching later is cheapdjango-deployment.com
Separate cache and broker instances so cache eviction never drops queued tasks.

Explanation

Django's cache framework abstracts the backend, so views and templates use the same API whichever you pick. The decision is therefore architectural: Redis is a general-purpose in-memory data store that happens to make a great cache, while Memcached is a purpose-built cache. In most Django stacks, Redis is already needed for Celery or Channels, and using it for caching too (on a separate instance with an LRU policy) keeps the system simpler.

Edge cases / notes

  • One Redis, many roles: different roles need different maxmemory-policy values; split into instances rather than databases (/0, /1), which share memory policy.
  • Large values (over 1 MB) need Memcached's -I tuning; Redis handles large values but they hurt latency.
  • Sessions: use cached_db with either backend so evictions do not log users out.
  • django-redis offers extra features (compression, client-side sharding) beyond Django's built-in backend.

Next steps

FAQ

Should I use Redis or Memcached with Django?

Redis for most projects, since it also handles sessions, Celery, and locks. Memcached for a pure, very large cache.

Is Memcached faster than Redis?

Both are extremely fast; for Django, network latency dominates. Memcached can be more memory-efficient for small values.

Can one Redis serve cache and Celery?

It can, but use separate instances so cache eviction does not remove queued tasks.

What is Valkey?

An open-source fork of Redis under the Linux Foundation, compatible with Django's Redis backend.

Keep going