Memcached

What it is

Memcached is an in-memory key/value store designed for one job: caching. It's multithreaded, event-driven, and deliberately simple — no persistence, no replication, no built-in clustering. You throw RAM at it across a fleet of nodes, clients hash keys to shard across those nodes, and it gets out of your way. It's been the default answer to "database is too slow" for two decades, predating Redis and most of the current data-layer tooling.

Who builds it and why

Originally built at Danga Interactive for LiveJournal in 2003, then picked up and hardened by the biggest web properties on the planet — Facebook, X (formerly Twitter), Reddit, YouTube, Wikipedia all run or ran it at scale. The GitHub repo (memcached/memcached) has 264 contributors and an active commit history, but it's not backed by a foundation or a company with a commercial arm. It's maintained by a small group of infra engineers, largely because they depend on it themselves. There's no CNCF backing (not publicly available whether it was ever considered), no VC-funded company behind it, and no enterprise support contract to buy. This is infrastructure built by the people who run it in production, for that exact purpose.

Production readiness signal

14,226 GitHub stars and 264 contributors is a mature, established signal — this isn't a project that's going to disappear. Commit activity is current (last commit 2026-05-18), meaning it's not abandonware despite its age. BSD-3-Clause license means no copyleft concerns for commercial use. What's missing from public data: no clear latest release tag, no founding date confirmation, no CNCF maturity level. That's consistent with a project that operates outside the CNCF governance model — it doesn't publish the same cadence of release notes or maturity docs you'd get from a foundation project. In practice, its production readiness is proven by two decades of continuous use at hyperscale companies, not by a badge on a website. If you're doing vendor due diligence, that lack of formal governance is a real gap to flag, even though the technical track record is rock solid.

Who should use this

Teams that need a pure, dumb, fast cache in front of a database or expensive computation — session storage, page fragment caching, API response caching, reducing read load on Postgres/MySQL. If your access pattern is "read-heavy, tolerant of cache misses, don't care about surviving a restart," Memcached is close to ideal. Its simplicity is the feature: fewer moving parts than Redis, lower memory overhead per key, and multithreading that scales better on many-core boxes for simple GET/SET workloads.

Who should NOT use this

Don't use it if you need persistence — a restart wipes everything, by design. Don't use it if you need data structures beyond strings/blobs (no lists, sets, sorted sets, streams). Don't use it if you need pub/sub, transactions, Lua scripting, or built-in replication/clustering — Redis wins here decisively. Don't use it if you need consistency guarantees across nodes; Memcached's sharding is client-side and eventual at best. And don't reach for it if your team already runs Redis for other things — running two caching systems for no reason is an ops tax you don't need.

Alternatives

• Redis / Valkey — richer data structures, persistence options, pub/sub, and now the dominant default for most greenfield caching needs.
• Dragonfly — drop-in Redis/Memcached-compatible engine claiming better multi-core throughput and lower memory overhead.
• Hazelcast — if you need a distributed cache with compute/grid capabilities beyond simple key/value.

Pricing

Fully open source, BSD-3-Clause. No paid tier, no enterprise edition, no vendor lock-in. You pay for the compute and ops effort to run it yourself — nothing else.