Redis vs Memcached: In‑Depth Technical Comparison of Features, Performance, and Architecture

Overview

Redis creator Salvatore Sanfilippo compared the two popular in‑memory data stores, Redis and Memcached, highlighting differences in server‑side operations, memory usage efficiency, and performance under various workloads.

Key Comparison Points

Server‑side data operations – Redis offers rich data structures and commands that can manipulate data directly on the server, eliminating extra network round‑trips required by Memcached, which only supports simple key‑value gets/sets.

Memory utilization – For plain key‑value storage Memcached achieves higher raw memory density, but Redis can achieve comparable or better efficiency when using hash structures with internal compression.

Performance – Redis runs single‑threaded, giving higher per‑core throughput for small values, while Memcached scales across multiple cores and outperforms Redis for large payloads (≈100 KB+).

Data Type Support

Redis supports five primary data types, each with its own command set, typical use cases, and internal implementation details.

1) String

Common commands: SET, GET, INCR, DECR, MGET etc.

Use case: Simple key/value storage.

Implementation: Stored as a redisObject whose encoding is either raw or int when the value can be interpreted as a number.

2) Hash

Common commands: HGET, HSET, HGETALL.

Use case: Storing objects such as a user profile (ID, name, age, birthday) where fields can be accessed individually.

Implementation: Internally a hash map; small hashes use a compact zipmap representation, larger ones switch to a true hash table ( ht).

3) List

Common commands: LPUSH, RPUSH, LPOP, RPOP, LRANGE.

Use case: Ordered collections such as Twitter follower lists.

Implementation: Doubly‑linked list enabling fast head/tail operations and reverse traversal, at the cost of extra memory overhead.

4) Set

Common commands: SADD, SPOP, SMEMBERS, SUNION.

Use case: Collections that require automatic deduplication and fast membership tests.

Implementation: Internally a hash map with null values, providing O(1) existence checks.

5) Sorted Set

Common commands: ZADD, ZRANGE, ZREM, ZCARD.

Use case: Ordered, deduplicated collections where each member has a score (e.g., Twitter public timeline sorted by timestamp).

Implementation: Combines a hash map (member → score) with a skip‑list for efficient range queries.

Memory Management Mechanisms

Redis does not keep every value permanently in RAM; when memory pressure rises it can swap rarely used values to disk using a custom algorithm ( swappability = age * log(size_in_memory)) and a background thread, which may block writes during swap.

Redis’s internal allocator is based on zmalloc (wrappers around malloc/free) that store the allocation size in a header, enabling easy tracking of total used memory via the used_memory variable.

Memcached employs a slab allocation scheme: memory is divided into classes of fixed‑size chunks (e.g., 88 B, 112 B, …) to eliminate fragmentation. Each incoming item is placed in the smallest fitting slab; freed chunks are returned to a free list. This yields high allocation efficiency but can waste space for variable‑size objects.

Persistence Support

Redis provides two persistence mechanisms, while Memcached offers none.

RDB Snapshots

Redis forks a child process that iterates over the dataset and writes an RDB file using copy‑on‑write. Snapshots can be triggered by time, write count, or a combination via the save command or CONFIG SET. The file is written to a temporary location and atomically renamed, ensuring a consistent snapshot even after crashes.

AOF (Append‑Only File) Log

Every write command is appended to an AOF file. Redis periodically rewrites the AOF to a compact form. The appendfsync setting controls durability: no (no explicit fsync), everysec (fsync every second), or always (fsync on every write).

For most workloads, RDB offers lower overhead; for applications that cannot tolerate data loss, AOF is recommended.

Cluster Management

Memcached is a pure in‑memory cache without native clustering; client libraries implement consistent hashing to distribute keys across multiple servers.

Redis supports native clustering (Redis Cluster). The key space is divided into 4096 hash slots; each node owns one or more slots. Master nodes have two replica slaves for redundancy, allowing the cluster to survive up to two simultaneous node failures. Slot assignment follows crc16(key) % 4096.

References

http://www.redisdoc.com/en/latest/

http://memcached.org/