Redis vs Memcached: Which Cache Fits Your Workload

Choose Memcached when you need a simple, multithreaded, volatile cache for pre-serialized values and are happy for the client to handle sharding. Choose Redis, or its BSD-licensed fork Valkey, when you need data structures, persistence, replication with automatic failover, or server-side sharding. Licensing is the other difference: Memcached is BSD licensed, Redis 8 is offered under RSALv2, SSPLv1 or AGPLv3, and Valkey is BSD.

Both keep data in memory and answer simple GET and SET requests quickly. The differences are in everything around that.

A Memcached item is a key, an expiry time, optional flags and raw bytes. The server stores whatever the client serialized and offers little beyond get, set, delete and simple increments. To change one field of a cached object, the client reads the whole value, deserializes it, edits it and writes it back, using check-and-set (CAS) if other writers might race it. Keys are limited to 250 characters.

Redis does that work on the server. You can increment one field of a hash, add a score to a sorted set or push onto a list in a single atomic command. That is why Redis gets used well beyond caching, for sessions, rate limits, leaderboards and queues; our guide to what Redis is used for covers each. If your application only stores rendered fragments or serialized query results, Memcached's simpler model costs you nothing.

Memcached treats forgetting as a feature. A restart used to mean an empty cache; since version 1.5.18, warm restart can recover the cache across clean restarts such as binary upgrades, with caveats: changing the memory limit, maximum item size or slab sizes starts it clean, and the system clock must not jump while it is down. A crash still means a cold cache. Extstore extends a node's capacity by keeping keys in RAM and values on flash, but it is a capacity feature, not durability.

Redis can persist with RDB snapshots, an append-only file or both, and reload the data on restart. It can also run with persistence off when it is used purely as a cache. The trade-offs, including how much each option can lose, are covered in our section on Redis persistence.

The practical test is what happens to your database when the cache empties. A cold cache sends every miss to the source of truth at once. If the database cannot absorb that, you need either a cache that survives restarts or a plan to warm it.

Memcached servers are unaware of each other. There is no crosstalk, synchronization or replication; the client picks a server for each key by hashing. Adding servers adds memory. Losing a server loses its share of the cache, and those keys miss until the application refills them. The Memcached documentation argues that replication would halve the usable cache and that an application should tolerate a few percent of extra misses.

Redis has replicas built in. Sentinel promotes a replica automatically when a primary fails, and Redis Cluster adds server-side sharding across several primaries. Replication is asynchronous, so a failover can drop the last writes, but the dataset survives the loss of a node. Choose Redis if a node failure must not empty part of the cache.

Memcached is multithreaded and starts four worker threads by default, so one process can use several cores. Redis executes commands on a single main thread. Redis 8 introduced a new I/O threading implementation, enabled with io-threads, that moves socket reads, request parsing and reply writes onto extra threads, and Valkey 8.0 reworked its I/O threading in the same direction. To use many cores for command execution, Redis's documentation still recommends running more instances or sharding.

Redis's benchmarking guide notes that Redis and Memcached in single-threaded mode can be compared fairly on GET and SET, and warns against comparing numbers from different benchmark tools. For most applications the network, the client library and the value size matter more than the server. Test with your own payloads before choosing on speed.

Memcached manages memory with a slab allocator. Memory is split into 1 MB pages, each page is assigned to a slab class with a fixed chunk size, and every class keeps its own LRU. An item is stored in the smallest chunk that fits it, so some bytes are wasted per item, and a workload whose item sizes drift over time can leave memory sitting in classes that no longer need it while other classes evict.

Redis allocates per key through its memory allocator. Fragmentation, replication buffers and the copy-on-write cost of the snapshot fork can push resident memory well above the dataset size; our Redis memory guide explains how to size for it. Neither is universally more compact. Load a representative sample of your data into each and measure.

Memcached fits when:

• you cache serialized objects, query results or page fragments under 1 MB
• losing part of the cache on a node failure is acceptable
• you want to scale a few large nodes vertically across many cores
• you want the smallest operational surface

Redis or Valkey fits when:

• you need data structures and atomic server-side operations
• the cache must survive restarts, or node failures must not lose data
• the same store also handles sessions, rate limiting, queues or leaderboards
• you want server-side sharding with automatic failover

If the Redis license is the concern, Valkey keeps the Redis feature set under BSD; our Valkey vs Redis comparison covers the differences.

Moving between the two is a cache migration, not a data migration: the new cache starts cold and fills from the source of truth, so the real work is sizing, client configuration and protecting the database while hit rates recover. AceMQ supports both sides: Memcached support for slab tuning, eviction and capacity, and Redis support and Valkey support for the persistence, replication and cluster questions that come with Redis.

• Memcached: About
• Memcached documentation: Overview and design philosophy
• Memcached documentation: Configuring (threads, item size)
• Memcached documentation: Performance and efficiency (slab classes, key length)
• Memcached documentation: Warm restart
• Memcached documentation: Flash storage (extstore)
• Memcached documentation: FAQ (replication, persistence)
• Memcached documentation: Use cases (1 MB item limit)
• Memcached: LICENSE (BSD)
• Redis: Strings (512 MB value limit)
• Redis: Persistence
• Redis: Key eviction
• Redis: Benchmarks
• Redis: Redis 8 GA announcement (new I/O threading)
• Redis: Redis Cluster specification
• Redis: Licenses
• Valkey: Project home (BSD license)
• Valkey: Unlock one million RPS (Valkey 8.0 I/O threading)