Redis or Memcached — which should I pick?

Default to Redis unless your workload is pure session/page caching with no need for data structures beyond string key-value. Redis covers ~95% of cache use cases plus everything Memcached can't — sorted sets, pub/sub, streams, geospatial, vector search via RediSearch. Pick Memcached when: (a) you specifically want multi-threaded throughput per node without Redis 6+ I/O threading, (b) your workload is genuinely just simple key-value with no growth-toward-structures, (c) operational simplicity matters more than feature breadth.

Is Memcached really faster than Redis?

Per single-thread, Memcached was historically marginally faster on pure GET/SET due to its multi-threaded architecture. Redis 6+ added I/O threading which closes the gap; Redis 7+ is competitive on pure throughput. For workloads where latency-per-op matters more than throughput-per-node, both are sub-millisecond. The throughput difference matters when you're running many cores per node — Memcached scales linearly across cores by design; Redis benefits from sharding to multiple instances.

What about persistence — does Memcached lose all data on restart?

Yes — Memcached is purely in-memory ephemeral. Restart loses everything. Redis offers RDB snapshots, AOF (append-only file), and hybrid persistence — you can configure durability from 'none' (acts like Memcached) to 'fsync every write' (acts like a primary store). For pure cache workloads where data loss is recoverable, persistence is overhead. For session stores, queues, or anything where rebuild cost matters, Redis's persistence options are valuable.

ElastiCache — does AWS charge differently for them?

Same per-instance-hour pricing on identical instance classes. The difference is in deployment options: Memcached on ElastiCache supports auto-discovery for client-side sharding; Redis offers Cluster mode + Sentinel + Multi-AZ replication. Memcached deployments are cheaper than Cluster-mode Redis (fewer shards needed for the same throughput) but lose multi-AZ. For production cache where data loss creates user-visible problems, Cluster-mode Redis is the right answer despite higher cost.

When should I migrate from Memcached to Redis?

When the workload outgrows pure key-value: needing pub/sub for cache invalidation, sorted sets for leaderboards, streams for event ingestion, or vector search. Also: when persistence becomes desirable (session store rebuilds, queue durability), when Multi-AZ failover matters, or when the team is operating both Memcached + Redis side-by-side and wants to consolidate. The migration is straightforward — clients largely treat both as 'cache that responds to GET/SET' — but client-library updates and operational learning are non-zero costs.

What about DragonflyDB or Valkey as alternatives?

DragonflyDB is a multi-threaded Redis-protocol-compatible engine claiming much higher throughput per node. Valkey is the Redis-fork that emerged after Redis's SSPL/RSAL licensing change. Both are alternatives to Redis itself, not to Memcached — they don't change the Redis-vs-Memcached decision. If you've already decided Redis-style data structures, see our Redis vs Valkey comparison . Memcached is for the genuinely-pure-key-value lane that all of Redis / Valkey / Dragonfly skip.

Sound familiar?

▸ Legacy Memcached deployment is starting to hold the app back — session stores, pub/sub cache invalidation, and leaderboard sorting all want Redis primitives that Memcached doesn't offer.
▸ "Just use a cache" — the team is debating Redis vs Memcached for a new service, and the answer depends on whether the workload will stay pure key-value or grow toward data structures.
▸ ElastiCache cost optimisation — you're running both Memcached and Redis clusters and consolidation could simplify ops, but the engine choice has to be defensible.

JusDB consultants build the Redis-vs-Memcached decision against your workload — and the migration runbook if you're consolidating. Book a cache-architecture review →

Redis vs Memcached

Short answer: Choose Redis for anything beyond a pure cache — data structures, pub/sub invalidation, leaderboards, sessions, persistence, Multi-AZ failover, or vector search; choose Memcached only when the workload is genuinely simple key-value, per-node multi-threaded throughput dominates, and operational simplicity matters more than features. Redis covers roughly 95% of cache use cases.

Rich data-structure server vs pure key-value cache. Persistence vs ephemeral. Multi-threading models, eviction strategies, ElastiCache pricing — the production-DBA view of cache-engine selection in 2026.

Feature matrix

Dimension	Redis 7+	Memcached 1.6+
Data types	String, Hash, List, Set, Sorted Set, Stream, HyperLogLog, Geospatial, Bitmap, Vector	String key-value only
Threading	Single-threaded core + I/O threads (6+) + Cluster sharding	Multi-threaded native — scales linearly per node
Persistence	RDB snapshots, AOF, hybrid — configurable from none to fsync-per-write	None — purely in-memory, restart loses everything
Replication / HA	Async replicas + Sentinel + Cluster mode native	No native replication; client-side sharding via consistent hashing
Pub/Sub	Channel-based + pattern-matching + Streams for durable	Not supported
Eviction policies	noeviction, allkeys-lru, allkeys-lfu, volatile-ttl, volatile-random, etc.	LRU only (per slab class)
Max value size	512 MB per value (most types)	1 MB default (configurable, but recommended < 4 MB)
Transactions	MULTI/EXEC + Lua scripting + WATCH for optimistic locking	No multi-key transactions; CAS for single-key consistency
Vector search	RediSearch / Redis Stack — HNSW, hybrid retrieval native	Not supported
Cloud-managed	ElastiCache Redis, MemoryDB, Redis Enterprise Cloud, Upstash	ElastiCache Memcached only (limited managed-service ecosystem)
License	SSPL/RSAL since 2024 (Valkey forked under BSD-3)	BSD — permissive, no copyleft
Best for	Cache + data structures + pub/sub + queues + sessions + leaderboards	Pure page / object caching where data structures aren't needed

When Redis wins

Cache + data structures (sorted sets for leaderboards, streams for events, geo).
Session store / token store / rate limiter — anything beyond pure HTTP cache.
Pub/Sub for real-time invalidation or low-latency event fanout.
Persistence matters — session continuity, queue durability, store-of-truth pattern.
Multi-AZ failover or Cluster mode is required for production reliability.
Vector search co-located with cache (RAG, semantic similarity).

When Memcached wins

Workload is genuinely pure key-value with no growth toward structures.
Per-node multi-threaded throughput is the dominant requirement.
BSD licence matters for redistribution scenarios.
Operational simplicity — fewer features means smaller surface to operate.
Auto-discovery client-side sharding fits the deployment pattern.
Cost-conscious deployments where Redis Multi-AZ overhead isn't justified.

Migration

Migration paths between Memcached and Redis

Memcached → Redis

Most common path. Clients largely treat both as GET/SET cache, but client-library updates are needed. Sized for new headroom — Redis with persistence + replication uses more RAM per stored byte than Memcached. We design the migration to handle dual-cache during cutover.

Redis → Memcached

Rare — usually licensing-driven (BSD license requirement) or simplicity-driven (operational team wants pure cache surface). Requires inventory of Redis features in use and replacement patterns for everything beyond key-value.

Polyglot pattern

Some teams keep Memcached for pure page-cache hot path + Redis for everything else. Operationally heavier but lets each engine play to its strengths. We help design the boundary.

Common questions

Need a written cache-engine decision?

We audit the workload, model the throughput and reliability requirements, and write the recommendation — for either engine or the polyglot answer.

Book a cache-architecture review Contact JusDB