Tech Duel
Redis vs Memcached
Redis supports rich data structures — sorted sets, streams, pub/sub — plus optional persistence, with 75.3k GitHub stars. Since Redis 8 (May 2025), it's triple-licensed under RSALv2, SSPLv1, and the OSI-approved open-source AGPLv3, reversing its earlier source-available-only period. Memcached is a pure key-value object cache with 14.2k stars and a BSD license. For anything beyond basic object caching, Redis is the appropriate choice.
Last reviewed: July 2026
Quick verdict: Redis vs Memcached
Choose Redis if you are building anything beyond a pure object cache: session storage, pub/sub, leaderboards, rate limiting, or queues.
Choose Memcached if you are running a read-heavy, high-concurrency object cache on existing infrastructure where your team already operates it, you have no need for persistence or data structures, and you want the simplest possible single-license caching layer.
Redis Cloud starts free at 30 MB and paid plans begin at $7/month, which is nothing compared to the engineering cost of bolting on a separate data structure service later.
The comparison below is the same for everyone. Your situation isn't.
When to choose Redis vs Memcached
Choose Redis when…
- You need session storage, rate limiting, pub/sub, leaderboards, or distributed locks
- You cannot tolerate a cold cache after restarts — Redis persistence preserves data
- You want a genuinely free managed tier (Redis Cloud, 30MB) with paid plans from $7/mo
- You need an OSI-approved open-source license — AGPLv3 is now an option since Redis 8
- Your use case will grow beyond simple key-value caching over time
Choose Memcached when…
- Your entire use case is caching serialized objects, no persistence or data structures
- You want maximum CPU efficiency for pure GET/SET workloads via multi-threading
- You want the simplest possible single-license story (BSD, no licensing history)
- Your team already operates Memcached in production with no expanding requirements
- You're not planning to need pub/sub, sorted sets, or persistence later
That's the generic picture. Whether you'll need anything beyond pure key-value caching is what usually tips it. ↓
Redis vs Memcached: performance benchmarks and latency in 2026
On raw throughput, both tools are fast enough that the difference rarely matters at the application layer. Both Redis and Memcached exceed 1 million GET operations per second on modern hardware, with sub-millisecond median latency under typical load. Memcached's simpler architecture — in-memory key-value with no persistence, pub/sub, or scripting overhead — gives it a slight edge on pure throughput for simple string values. Independent benchmarks consistently show Memcached outperforming Redis by 10–20% for sustained high-concurrency reads of small, uniform objects.
Redis closes that gap and often surpasses Memcached once you factor in data structure operations. Incrementing a counter in Redis is a single atomic INCR; the equivalent in Memcached requires a read-modify-write with client-side logic or a CAS (check-and-set) loop. For sorted sets, lists, HyperLogLog approximations, or geospatial lookups, Redis has no equivalent competition — Memcached forces you to serialize and manage those structures in your application code, adding latency and complexity. Redis 7+ also offloads I/O and command parsing across threads while keeping execution single-threaded for atomicity, which improves throughput on multi-core hosts compared to older Redis versions.
The practical rule: if you are caching simple HTML fragments, API responses, or session tokens with uniform short TTLs, Memcached's simpler operation model and comparable throughput make it a valid choice with less operational surface area. If your cache operations involve anything beyond GET/SET — leaderboards, rate-limiting counters, pub/sub fan-out — Redis is the only option with native support for those patterns.
Throughput parity at 1M+ ops/sec means the architecture decision is driven by data structure needs and operational simplicity, not raw speed alone.
Redis vs Memcached: what changed in 2026 — Redis's license, again
The licensing story that used to be Memcached's clearest advantage has substantially shifted. Redis moved away from open source in 2024, dual-licensing under the Redis Source Available License (RSALv2) and the Server Side Public License (SSPLv1), a change that sparked enough community backlash that AWS, Google, Oracle, and others backed a BSD-licensed fork called Valkey under the Linux Foundation. In May 2025, with the Redis 8 general availability release, Redis reversed course: it's now triple-licensed under RSALv2, SSPLv1, and the OSI-approved open-source AGPLv3. Teams that specifically needed a genuine open-source license, not just source-available, can now use Redis under AGPL instead of switching to Memcached or Valkey for that reason alone.
This doesn't erase the episode. AGPL carries its own network-copyleft obligations that Apache 2.0 or BSD don't, so it isn't a drop-in equivalent to Memcached's permissive license, and some engineering teams that already migrated to Valkey during the 2024 controversy have stayed there rather than migrate back, treating the licensing reversal as a goodwill gesture that corporate governance could revisit again. Valkey itself has continued shipping independently as a genuine BSD-licensed, wire-compatible alternative under Linux Foundation governance.
Practically: if your team ruled out Redis in 2024 purely because it "wasn't open source anymore," that's no longer accurate — AGPLv3 is a real option today. If your team already completed a Valkey migration, there's little reason to migrate back purely over licensing; Valkey remains a solid, actively maintained, BSD-licensed alternative.
If a comparison you're reading treats Redis as "no longer open source" without mentioning the May 2025 AGPLv3 option, it predates that change and is giving you outdated licensing advice.
Common questions about Redis vs Memcached
What is the main difference between Redis and Memcached in 2026?
Redis (75.3k GitHub stars, triple-licensed under RSALv2/SSPLv1/AGPLv3 since Redis 8, free Cloud tier at 30 MB) is a full data structure server supporting sorted sets, streams, pub/sub, and persistence. Memcached (14.2k stars, BSD license, no managed free tier) is a pure key-value object cache. If you need anything beyond caching serialized blobs, Redis is the correct choice. Memcached wins when you need maximum CPU efficiency for pure caching with the simplest possible single-license story.
Which is cheaper, Redis or Memcached, for a managed cloud deployment?
Redis is cheaper to start. Redis Cloud has a free 30 MB tier and paid plans from $7/month. No major cloud provider offers a free managed Memcached tier. AWS ElastiCache for Memcached starts at approximately $0.017/hour (roughly $12/month) for the smallest node. For prototypes and small production deployments, Redis Cloud is the lower-cost managed entry point.
Does Redis's licensing history still matter now that AGPLv3 is back?
Less than it did in 2024, but it's not nothing. Since Redis 8 (May 2025), Redis is triple-licensed under RSALv2, SSPLv1, and the OSI-approved open-source AGPLv3, so teams that need genuine open-source terms have a real option again. For most application developers using Redis to cache data or run sessions, none of the three licenses meaningfully restricts you — RSALv2 and SSPLv1 primarily target companies building competing managed Redis services. What's changed less: some teams that migrated to Valkey during the 2024 controversy view the AGPL reversal as a goodwill gesture that corporate governance could revisit, and have stayed on Valkey rather than migrate back. If your organization has a formal open-source license review process, budget time for legal either way — and know that Valkey (Linux Foundation, BSD-licensed, wire-compatible) remains a solid alternative if you want to sidestep the question entirely.
What is the most dangerous production failure with Redis that teams discover too late?
Memory fragmentation. After months of production use with mixed key sizes and high key churn, Redis's allocator fragments heap memory so badly that the OS process consumes 2x or more the RAM that Redis itself reports. Your maxmemory limit never triggers because Redis thinks it has headroom. The OOM killer terminates Redis without warning. The fix is enabling active-defrag in redis.conf before you go to production, not after the 3 AM incident.
Can I switch from Memcached to Redis without rewriting my application?
Mostly yes, for basic usage. The GET/SET/DELETE interface maps almost directly between client libraries, and the migration is primarily an infrastructure task taking one to two weeks. The code changes are minimal if you only use basic caching. The operational changes are real: you need to configure eviction policies, persistence settings, and update your monitoring to track Redis-specific metrics like used_memory_rss versus used_memory. Switching from Redis to Memcached is harder if you have used Redis-specific features like sorted sets or pub/sub.
Should a team that already migrated to Valkey consider moving back to Redis now?
Usually no, unless a specific Redis-only feature justifies the migration cost. Valkey is a genuine, actively maintained, BSD-licensed fork under Linux Foundation governance with strong backing from AWS, Google, and Oracle, and it remains wire-compatible with Redis clients. Redis's AGPLv3 option removes the original reason many teams left, but a migration back carries its own cost and risk for no functional gain if Valkey is already meeting your needs. The AGPL reversal is more relevant for teams evaluating Redis fresh in 2026 than for teams that already completed a Valkey migration.