Valkey vs Memcached in 2026: two BSD caches, one decision
Most Redis-vs-Memcached comparisons are really a licensing argument. Between Valkey and Memcached that argument disappears: both ship under a permissive BSD license. What is left is a clean technical choice between a rich data-structure store and a minimal multithreaded cache.
The license drama does not apply here
The reason so many teams evaluate Valkey at all is the Redis license change: Redis moved from BSD to SSPL and RSALv2 in March 2024, then added AGPLv3 in May 2025. That copyleft is uncomfortable for a lot of commercial shops, and it is what drove AWS, Google, Oracle, and Ericsson to launch the Valkey fork. See the full license timeline for the sequence.
None of that touches this comparison. Memcached has been BSD-3-Clause since it was released in 2003, and Valkey is BSD-3-Clause by design. Both are OSI-approved, permissive, and free of managed-service restrictions. If licensing is what pushed you off Redis, you can pick either of these on legal grounds alone and then decide purely on the technical fit below.
Valkey 9.1 vs Memcached 1.6: side-by-side
| Feature | Valkey | Memcached |
|---|---|---|
| License | BSD-3-Clause (permissive, OSI) | BSD-3-Clause (permissive, OSI) |
| Data model | Strings, hashes, lists, sets, sorted sets, streams, bitmaps, HLL, geo | Strings only (opaque key-value) |
| Persistence | RDB snapshots + AOF (optional) | None (pure in-memory) |
| Replication | Yes (primary + replicas) | None (client-side sharding) |
| Clustering | Native cluster mode (hash slots) | Client-side consistent hashing |
| Threading | Multi-threaded I/O (redesigned 8.0) | Multithreaded since 2003 |
| Pure GET/SET throughput | Fast | ~20-25% faster at high concurrency |
| Max value size | 512MB (string) | 1MB default (raise with -I) |
| Pub/Sub, Lua, transactions | Yes | No |
| Vector / similarity search | valkey-search module (GA Jul 2025) | No |
| Current version | 9.1.x (May 2026) | 1.6.x (1.6.44, Jul 2026) |
| AWS managed | ElastiCache for Valkey (default engine) | ElastiCache for Memcached |
| GCP managed | Memorystore for Valkey | Memorystore for Memcached |
Sources: valkey.io, memcached wiki, endoflife.date. Throughput edge per this site's benchmark page.
Pick Memcached if...
Your workload is a pure ephemeral cache of string values
If you only ever GET and SET opaque blobs (rendered fragments, serialized objects, session tokens) and never need a data structure, Memcached does exactly that and nothing else. Less machinery per request means more requests per core.
You want maximum GET/SET throughput per dollar at high concurrency
Memcached has been multithreaded since 2003 and its slab allocator keeps per-request bookkeeping minimal. On the narrow pure-cache benchmark it holds roughly a 20-25% throughput edge over Redis/Valkey at high concurrency.
Cache loss is acceptable and you want the simplest operational model
No persistence, no replication, no failover to reason about. A node dies, its keys repopulate from the source of truth. For a caching tier in front of a database, that is often the correct, boring design.
You scale by adding stateless nodes
Memcached's client-side consistent hashing means scaling out is just adding nodes to the client's server list. No cluster protocol, no resharding orchestration.
Pick Valkey if...
You need data structures, not just string keys
Sorted sets for leaderboards and rate limiters, hashes for object fields, lists for queues, streams for event logs, pub/sub for fan-out. Memcached has none of these; Valkey makes them one command away, which often lets you delete a second piece of infrastructure.
You need persistence or replication
Valkey offers RDB snapshots, AOF, primary-replica replication, and native clustering. If a cold cache after a restart would hurt (thundering herd on your database), Valkey's durability options matter and Memcached cannot provide them.
You are on AWS ElastiCache or Google Memorystore
Both clouds default new deployments to Valkey and price ElastiCache for Valkey about 20% below Redis OSS on node-based clusters. If you are provisioning managed cache today, Valkey is the path of least resistance and lowest bill.
You want one store that also caches, instead of a cache plus a data store
Teams frequently run Memcached for caching and then add Redis for queues, locks, or leaderboards. Valkey collapses that into a single BSD-licensed engine, cutting operational surface area.
Where does Redis fit? The three-way view
Search traffic for "memcached vs redis vs valkey" is really asking one question: now that Valkey exists, when is Redis 8.0 still worth its license? The honest answer for most teams is a short list. Redis 8.0 ships vector sets (VADD/VSIM) as a core data type and the proprietary Redis Stack modules (RedisJSON, RediSearch) that Valkey matches only through separate modules with not-identical behaviour. If you need those specifically, or you hold a commercial Redis Cloud SLA, Redis 8.0 earns its place.
For everyone else the contest has narrowed to Valkey vs Memcached, because Valkey removed the license reason to prefer Redis while keeping the Redis feature set. So: Memcached for the narrowest, fastest pure cache; Valkey for anything richer; Redis 8.0 for the specific vector-set or Redis Stack workload. Compare the fork more closely on Valkey vs Redis.
FAQ
What is the difference between Valkey and Memcached?
Memcached is a minimal multithreaded key-value cache: strings only, no persistence, no replication, client-side sharding. Valkey is the BSD-licensed Linux Foundation fork of Redis 7.2.4 and a superset: it keeps the same jobs but adds hashes, lists, sets, sorted sets, streams, pub/sub, Lua scripting, RDB/AOF persistence, replication, and clustering. Memcached wins on raw GET/SET throughput at high concurrency (roughly a 20-25% edge in independent benchmarks) because it was multithreaded from its 2003 start and does less per request. Valkey wins everywhere you need data structures, durability, or a single store that does more than caching.
Do Valkey and Memcached have the same license?
Yes, near enough. Both ship under a permissive BSD license (Memcached under BSD-3-Clause, Valkey under BSD-3-Clause). This is the point most comparisons miss: the SSPL and AGPLv3 licensing drama that pushed teams off Redis in 2024-2025 does not exist for either Valkey or Memcached. If your procurement team blocked Redis over SSPL, both of these are clean, OSI-approved, permissive options. License is not a differentiator between Valkey and Memcached; the technical fit is.
Memcached vs Redis vs Valkey, which should I pick?
Pick Memcached for a pure ephemeral cache where you want maximum GET/SET throughput per dollar and need nothing but string keys. Pick Valkey when you want Redis-style data structures, persistence, and replication under a clean BSD license with no Redis Inc licensing strings and it is the default engine on AWS ElastiCache and Google Memorystore for new clusters. Pick Redis 8.0 only when you specifically need its core vector set data type (VADD/VSIM) or Redis Stack modules (RedisJSON, RediSearch) that Valkey does not match one-for-one. For most teams choosing an open-source engine in 2026, the real contest is Valkey vs Memcached, because Valkey removed the license reason to prefer Redis.
Can Valkey replace Memcached?
Functionally yes, but not as a wire-compatible drop-in. Valkey speaks the Redis RESP protocol; Memcached speaks its own text and binary protocols, so switching means changing your client library from a memcached client to a Redis/Valkey client (redis-py, ioredis, Jedis, go-redis all work). Once migrated, Valkey covers every Memcached use case and adds persistence and data structures. The trade-off is that Memcached's multithreaded core still edges Valkey on pure GET/SET throughput at very high concurrency, so a cache doing nothing but simple string reads may not benefit from the switch.
Is Memcached still faster than Valkey in 2026?
For pure GET/SET on small string values at high concurrency, Memcached typically holds a roughly 20-25% throughput edge because it has been multithreaded since 2003 and its slab allocator does less bookkeeping per request. Valkey narrowed the gap with the multi-threaded I/O redesign it inherited and improved in the 8.0 line, but Memcached still leads on the narrowest cache benchmark. Once the workload needs data structures, atomic counters, pub/sub, or persistence, the throughput comparison stops being apples-to-apples because Memcached cannot do those jobs at all.