memcached vs Redis

Redis (created by Salvatore Sanfilippo in 2009 as a side project while working on a real-time web analytics platform, grew into the world's most popular in-memory data store, now maintained by Redis Ltd after the controversial 2024 license change from BSD to dual RSALv2/SSPL, used by Twitter, GitHub, Pinterest, Snapchat, Stack Overflow, and millions of applications worldwide) and Memcached (created by Brad Fitzpatrick in 2003 originally to speed up LiveJournal's page loads, BSD-licensed and maintained by the open-source community, used by Facebook, Wikipedia, YouTube, and countless web applications for over two decades) are both in-memory key-value stores used primarily for caching, but Redis has evolved far beyond simple caching into a multi-model data platform while Memcached remains focused on its original purpose of high-performance distributed key-value caching with minimal overhead.

Architecture and Philosophy

Redis is single-threaded for command execution by design—a deliberate architectural choice that eliminates lock contention, simplifies the programming model, and makes every operation inherently atomic without explicit locking. A single Redis instance uses an event-driven architecture (epoll/kqueue) that handles 100,000-200,000+ operations per second on a single CPU core for typical commands. Redis thinks in data structures—not just key-value pairs, but strings, hashes (field-value maps), lists (doubly-linked lists), sets (unique unordered collections), sorted sets (sets ordered by floating-point score), streams (append-only logs), bitmaps (bit-level operations), HyperLogLog (probabilistic cardinality estimation), and geospatial indexes (longitude/latitude with radius queries). Each data structure has purpose-built atomic operations (LPUSH/RPOP for queues, SADD/SINTER for set operations, ZINCRBY for leaderboard score updates) that execute without any possibility of race conditions. Redis can persist data to disk via RDB snapshots or AOF (Append Only File), replicate to follower instances for high availability, and cluster across multiple nodes for horizontal scaling. Redis has evolved from "cache" to "data structure server" to "real-time data platform" over its 15-year history.

Memcached is multi-threaded with the simplest possible architecture: keys map to byte-string values, values are stored in memory using a slab allocator with LRU (Least Recently Used) eviction, and that is the entire feature set. No persistence, no data structures beyond opaque byte strings, no pub/sub messaging, no server-side scripting, no replication, no clustering. Memcached does exactly one thing—cache key-value pairs in memory with sub-millisecond latency—and does it with minimal per-key overhead and maximum operational simplicity. The multi-threaded architecture means a single Memcached instance utilizes all available CPU cores, handling many concurrent connections efficiently across threads with fine-grained locking on the hash table. This threading model gives Memcached an advantage for specific workloads: many concurrent clients performing simple get/set operations on large values where CPU parallelism matters more than data structure richness.

Feature Deep-Dive

Data structures: Redis supports strings (up to 512MB, with atomic increment/decrement, bit operations, and substring manipulation), hashes (field-value maps ideal for representing objects—HSET user:1000 name "Alice" age 30 email "[email protected]"—with O(1) field access), lists (doubly-linked lists with O(1) push/pop at both ends, blocking pop for queue patterns, and range queries), sets (unique unordered collections with O(1) membership testing and set operations—intersection, union, difference—across multiple sets), sorted sets (the most powerful Redis data structure—elements ordered by floating-point score with O(log n) insertion, O(log n) rank queries, range queries by score or rank, and atomic score increment—perfect for leaderboards, rate limiters, priority queues, and time-based expiration), streams (append-only log data structure for event sourcing, message queues with consumer groups, acknowledgment, and message history—similar to Apache Kafka for simpler use cases), bitmaps (bit-level operations for space-efficient flags, counters, and bloom filters—track 100 million user daily logins in 12.5MB), HyperLogLog (probabilistic cardinality estimation—count unique visitors with 0.81% standard error using only 12KB regardless of cardinality), and geospatial indexes (store longitude/latitude coordinates, query by radius or bounding box, calculate distances between points).

Memcached supports strings only. A key (up to 250 bytes) maps to a value (up to 1MB by default, configurable to larger sizes via slab configuration). The value is an opaque blob of bytes—Memcached does not interpret, index, or operate on the content. If you need a list, you serialize it to bytes, store it, retrieve it, deserialize it, modify it, re-serialize it, and store it again—with no atomicity guarantee between the get and set (another client might modify it between your read and write). If you need a sorted set, you implement the entire data structure in application code with all the race condition handling that implies. The simplicity is intentional and has real benefits—fewer features mean fewer bugs, less memory overhead per key, more predictable performance characteristics, and a smaller attack surface.

Persistence and durability: Redis offers two persistence mechanisms that can be used independently or combined. RDB (Redis Database Backup) takes point-in-time snapshots at configurable intervals (e.g., "save after 60 seconds if at least 1000 keys changed"). The snapshot is created by forking the Redis process—the child writes the snapshot to disk while the parent continues serving requests with zero downtime. RDB files are compact and ideal for backups and disaster recovery. AOF (Append Only File) logs every write operation to disk, providing durability guarantees configurable from "fsync every second" (recommended—at most 1 second of data loss on crash) to "fsync every write" (maximum durability, lower throughput) to "never fsync" (OS decides, fastest but least durable). You can combine both: AOF for durability, RDB for fast restart and backup. With AOF fsync-every-second, Redis survives process crashes and server reboots with at most 1 second of data loss—making it suitable as a primary data store for use cases like session storage, rate limiting state, and real-time analytics where losing the last second of data is acceptable.

Memcached has zero persistence. When the Memcached process stops—whether from a crash, restart, deployment, or server reboot—all data is gone instantly. This is by design and is a feature, not a limitation, within Memcached's philosophy. Memcached is purely a cache—a performance optimization layer in front of your primary database. Your application must handle cache misses gracefully by fetching from the authoritative data source (PostgreSQL, MySQL, MongoDB, or whatever your primary database is). This simplicity means Memcached never has persistence-related performance overhead, never needs disk I/O configuration, never has AOF rewrite pauses, and never has fork-related memory spikes. The operational model is dead simple: if Memcached dies, restart it, and the cache warms up naturally as requests flow through.

Pub/Sub and messaging: Redis Pub/Sub enables publish-subscribe messaging between connected clients in real-time. Publishers send messages to channels; all subscribers to that channel receive the message instantly. This enables real-time features like chat applications, live notifications, collaborative editing presence indicators, and live dashboard updates. Redis Streams (added in version 5.0, 2018) provide a more durable and sophisticated message queue: messages persist in the stream (unlike Pub/Sub where undelivered messages are lost), consumer groups allow multiple consumers to process messages cooperatively (each message delivered to one consumer in the group), acknowledgment ensures messages are not lost if a consumer crashes, and pending entry lists track unacknowledged messages for redelivery. For many applications, Redis Streams eliminate the need for a separate message broker like RabbitMQ or a simpler Kafka deployment.

Memcached has absolutely no messaging capabilities. If you need pub/sub, event streaming, message queues, or any form of inter-process communication, you need a completely separate system. This is fine for pure caching use cases but means Memcached cannot serve the "Swiss Army knife" role that Redis fills in many architectures.

Scripting and atomic operations: Redis supports Lua scripting—execute arbitrarily complex operations atomically on the server side without any possibility of interleaving with other commands. A Lua script can read multiple keys, perform calculations, conditionally write results, and return values—all as a single atomic operation from the perspective of other clients. This enables patterns that would be impossible or race-condition-prone with individual commands: "read the current rate limit counter, check if it exceeds the threshold, increment it if not, and set expiry—all atomically" becomes a single Lua script execution. Redis 7.0 added Redis Functions—persistent server-side functions that survive restarts (unlike Lua scripts which must be re-sent by clients), with library management and better debugging support.

Memcached has no server-side scripting. All logic must live in application code, requiring multiple network round-trips for complex operations. Memcached does support CAS (Compare-And-Swap) for optimistic locking—check that a value has not changed since you read it before writing—but this is limited to single-key operations and requires retry loops in application code when conflicts occur. For complex multi-key atomic operations, Memcached simply cannot help.

Clustering and high availability: Redis Cluster (available since 3.0, 2015) automatically shards data across multiple nodes using hash slots (16,384 slots distributed across primary nodes). Each primary has one or more replicas for failover. If a primary fails, its replica is automatically promoted. The cluster handles resharding (moving slots between nodes) online without downtime. Redis Sentinel provides high availability for non-clustered deployments—it monitors Redis instances, detects failures, and performs automatic failover to replicas with client notification. For most deployments, a single Redis instance with a replica (Sentinel-managed) provides sufficient availability and performance.

Memcached scales horizontally via client-side consistent hashing—the client library (not the server) determines which Memcached server holds each key using a hash ring algorithm. There is no built-in clustering, no server-side replication, and no automatic failover. If a Memcached node dies, its portion of the keyspace is lost (cache misses, not data loss since Memcached is just a cache), and the client routes those keys to remaining nodes. Adding or removing nodes causes cache redistribution (some keys hash to different servers). This simplicity means zero operational complexity on the server side—each Memcached instance is independent and stateless—but no automatic recovery from node failures.

Memory efficiency and performance characteristics: Memcached has slightly better memory efficiency for simple string caching because it has less per-key overhead. Redis stores type information, encoding metadata, expiry timestamps, and LRU clock data for every key. Memcached's slab allocator stores raw bytes with minimal metadata. For workloads caching millions of small values (session tokens, rendered HTML fragments, serialized objects), Memcached uses 10-20% less memory per key. This difference is meaningful at very large scale (hundreds of gigabytes of cache) but negligible for most deployments.

For large values (>100KB), Memcached's multi-threaded architecture provides better throughput because multiple threads can simultaneously read/write large values from/to network sockets. Redis's single-threaded command execution means a single large value read (GET of a 5MB blob) blocks all other commands for the duration of the network transfer. Redis 6.0 added I/O threading (multi-threaded network read/write) which helps with large values, but command execution remains single-threaded. For workloads dominated by large value transfers with high concurrency, Memcached's threading model provides measurably better throughput.

Eviction policies: Redis offers 8 eviction policies: noeviction (return errors when memory full), allkeys-lru (evict least recently used across all keys), volatile-lru (evict LRU among keys with expiry set), allkeys-lfu (evict least frequently used), volatile-lfu (LFU among expiring keys), allkeys-random, volatile-random, and volatile-ttl (evict keys closest to expiry). The LFU (Least Frequently Used) policies are particularly valuable—they keep frequently accessed hot data in cache even if it was not accessed in the last few seconds, which LRU would evict. You can choose the optimal eviction strategy for your workload.

Memcached uses LRU eviction only, implemented per slab class. When a slab is full, the least recently used item in that slab is evicted. This is simple and works well for most caching patterns but cannot be tuned for workloads where frequency-based eviction would be more appropriate.

Pricing and Licensing Reality

Redis: the licensing situation changed dramatically in 2024. Redis Ltd changed the license from BSD (truly open-source, used by everyone freely) to dual RSALv2/SSPL. This prevents cloud providers from offering Redis-as-a-service without a commercial agreement with Redis Ltd. The community response was swift: AWS, Google, Oracle, Ericsson, and others forked Redis to create Valkey (maintained by the Linux Foundation, BSD-licensed, functionally identical to Redis at the fork point). For new deployments, you must choose: Redis (Redis Ltd, commercial license for cloud providers) or Valkey (Linux Foundation, BSD-licensed, community-maintained). AWS ElastiCache and MemoryDB now default to Valkey. Google Cloud Memorystore supports both.

Redis Cloud (Redis Ltd's managed service): free 30MB tier, Essentials from $7/month (250MB), Pro from $100+/month with advanced features. AWS ElastiCache for Redis/Valkey: cache.t3.micro from ~$12/month, scaling to thousands per month for large clusters. Google Memorystore, Azure Cache for Redis provide similar managed offerings.

Memcached: BSD-licensed open-source with no licensing concerns whatsoever. No company controls it, no license changes are possible, no forks are necessary. AWS ElastiCache for Memcached, Google Memorystore for Memcached provide managed services at similar pricing to Redis equivalents. Self-hosting is trivial—Memcached has minimal configuration and operational requirements.

The 2024 Redis license change is the most significant factor in the Redis vs Memcached decision that did not exist before. If licensing freedom matters to your organization, Valkey (Redis-compatible, BSD-licensed) or Memcached (always BSD) are the safe choices. If you use a managed service (ElastiCache, Memorystore), the licensing is handled by the cloud provider regardless.

When to Choose Redis (or Valkey)

Choose Redis for virtually any in-memory data need beyond simple string caching: session storage with structured data (hash per session), rate limiting (sorted sets with sliding windows), leaderboards and rankings (sorted sets with ZRANGEBYSCORE), real-time analytics (HyperLogLog for unique counts, bitmaps for daily active users), message queues and event streaming (Streams with consumer groups), pub/sub for real-time notifications, geospatial queries (find nearby users/stores), distributed locks (Redlock algorithm), and caching with intelligent eviction (LFU keeps hot data). Choose it when you need persistence (surviving restarts without cold cache penalty). Choose it when you need atomic operations on complex data (Lua scripting). Choose it when you need high availability with automatic failover (Sentinel or Cluster). Redis (or its Valkey fork) is the default choice for in-memory data in 2024—choose Memcached only if you have a specific reason.

When to Choose Memcached

Choose Memcached only for simple key-value string caching where: you cache large values (>100KB) with many concurrent connections and need multi-threaded throughput, you explicitly do not want persistence (pure cache with database fallback, simplest possible operational model), you do not need any data structures beyond opaque byte strings, you want the absolute simplest operational model (no replication configuration, no cluster management, no persistence tuning), and licensing simplicity matters (BSD forever, no corporate control). In practice, this is a narrow and shrinking use case. Facebook's massive Memcached deployment (the largest in the world) is the canonical example—billions of simple key-value lookups per second where Memcached's multi-threaded simplicity at extreme scale justified the choice. For most new projects that are not operating at Facebook scale, Redis or Valkey is the better default.

The Honest Trade-offs

Redis's trade-offs: single-threaded command execution means one slow command (KEYS *, SORT on large sets, large Lua scripts) blocks all other clients—use SCAN instead of KEYS, avoid O(n) operations on large collections, and keep Lua scripts short. The 2024 license change from BSD to RSALv2/SSPL creates uncertainty about the project's future direction under Redis Ltd's control—consider the Valkey fork for BSD-licensed Redis compatibility. Memory usage is higher per key than Memcached due to data structure metadata, type information, and persistence bookkeeping. Redis complexity (persistence configuration, replication topology, cluster slot management, Lua scripting, eviction policy selection) means more operational knowledge required than Memcached's "start it and forget it" model. Redis can become a single point of failure if used as a primary data store without proper replication and monitoring—treat it with the same operational seriousness as your primary database if you store non-cacheable data in it.

Memcached's trade-offs: no persistence means all data is lost on restart (cold cache problem—your database gets hammered until the cache warms up), no data structures means implementing complex patterns in application code with race conditions, no pub/sub or messaging means needing additional infrastructure for real-time features, no built-in replication or failover means node failures cause cache misses until the node recovers, and the project receives minimal active development compared to Redis's rapid feature evolution. Memcached is effectively feature-complete and maintenance-mode—it does what it does well but will not gain new capabilities. The community is small and shrinking as Redis dominates the mindshare. For new projects in 2024, there is rarely a compelling technical reason to choose Memcached over Redis/Valkey unless you specifically need multi-threaded large-value caching at extreme scale or you are adding caching to an existing system that already uses Memcached.

Operational Considerations and Migration

For teams currently running Memcached considering a migration to Redis, the transition is straightforward for simple caching patterns. Both use TCP connections with text or binary protocols, and most application frameworks (Django, Rails, Spring, Laravel) support swapping cache backends with a configuration change. The cache warms up naturally after switching—no data migration is needed since cache data is ephemeral by definition. The main migration work is updating client libraries and connection configuration.

For teams running Redis and concerned about the 2024 license change, migrating to Valkey is nearly zero-effort. Valkey is wire-protocol compatible with Redis—change the server binary, keep the same configuration, and clients connect without modification. AWS ElastiCache performed this migration transparently for millions of Redis instances. The Valkey community is actively developing new features (including multi-threading improvements for command execution) that may eventually differentiate it from Redis Ltd's version.

Feature	memcached	Redis
Sugggest Score	—	31
User Rating	—	⭐ 4.1/5 (16)
Category	Network & Admin	Development
Pricing	Open Source	Open Source
Ease of Use	—	3.5/5
Features Rating	—	4.6/5
Value for Money	—	4.4/5
Customer Support	—	2.9/5

Product Overview

memcached

Description: Memcached is an open source, high-performance distributed memory object caching system. It is used to speed up dynamic web applications by alleviating database load for reading/writing frequently accessed data.

Redis

Description: Redis is an open-source, in-memory data structure store, used as a database, cache and message broker. It supports data structures such as strings, hashes, lists, sets, sorted sets with range queries, bitmaps, hyperloglogs, geospatial indexes and streams.

Key Features Comparison

memcached Features

• In-memory key-value store
• Distributed architecture
• Simple protocol
• Horizontal scalability

Redis Features

• In-memory data structure store
• Supports various data structures (strings, hashes, lists, sets, sorted sets, bitmaps, hyperloglogs, geospatial indexes, streams)
• Used as a database, cache, and message broker
• Provides high performance and low latency
• Supports replication, clustering, and high availability
• Supports a wide range of programming languages
• Provides a rich set of commands and APIs
• Supports data persistence (RDB and AOF)

Pros & Cons Analysis

memcached

Pros

• Very fast data lookup
• Reduces database load
• Improves overall application performance

Cons

• Data loss on server restart
• Additional system complexity
• Requires application code changes

Redis

Pros

• High performance and low latency
• Flexible and versatile data structures
• Supports a wide range of use cases
• Easy to set up and configure
• Scalable and highly available
• Open-source and free to use

Cons

• In-memory nature can lead to data loss in case of system failures
• Complexity in setting up and maintaining a highly available Redis cluster
• Limited support for transactions and complex queries compared to traditional databases
• Potential for high memory usage, especially for large datasets

Pricing Comparison

memcached

• Open Source

Redis

• Open Source