Cloud Parts

Memcached

A simple, multithreaded in-memory key-value cache; clients hash keys across independent servers.

What it is
Key-value stores
Used for
Caching
Type
Open source
Made by
Memcached open-source project (originally Danga Interactive)
License
BSD-3-Clause
Facts checked
6 October 2026
Website Source code

What it is

Memcached keeps small values (strings, serialised objects, rendered fragments) in RAM under a key, with an expiry time, and offers little more than get, set, delete and atomic incr/decr. It doesn’t understand the data and can’t query inside it. A cluster is just a list of servers that know nothing about each other: no replication, no gossip, no coordination. The client library hashes each key to pick a server, so adding servers adds memory, and a dead server costs only its share of the keys, which then miss and are reloaded from the database. Every command is designed to be O(1), and docs say a request should take well under a millisecond even on slow machines.

Inside, memory is split into 1 MB pages that are cut into chunks of fixed sizes, the slab allocator, so the server never fragments memory or waits for a garbage collector; each slab class keeps its own LRU, and the oldest items are evicted when memory is full. The server is multithreaded (four worker threads by default) on top of libevent. Since its first release it has added a binary protocol (1.4.0, 2009), a newer “meta” text protocol, TLS (1.5.13), warm restarts that keep the cache across a clean restart (1.5.18), extstore, which keeps keys in RAM but moves large values to flash (experimental in 1.5.4, 2017), and a built-in proxy for routing between pools (1.6.23). The latest stable release is 1.6.45 (July 2026).

Why teams pick it

  • Very simple to run and reason about: one binary, a few flags, no cluster state to repair
  • Multithreaded and O(1), so one server uses several cores and keeps latency flat under load
  • Scales out by adding servers; clients spread keys and servers never coordinate
  • Proven at very large scale: Facebook’s NSDI 2013 paper describes billions of requests per second and trillions of items on memcached

Watch out for

  • A cache only: no replication, no persistence beyond warm restarts, no snapshots, so a lost node loses its keys
  • Values are opaque blobs (1 MB by default); no lists, sets, sorted sets or queries, unlike Valkey or Redis
  • Exposed servers have been abused for UDP amplification DDoS attacks; UDP is off by default since 1.5.6, and servers belong behind a firewall
  • Managed options are shrinking: Google is deprecating Memorystore for Memcached (shutdown January 2029) in favour of Valkey, and ElastiCache Serverless prices Valkey 33% below Memcached

Alternatives

What all key-value stores have in common →
Amazon DynamoDBAWSAWS’s serverless key-value and document database, with single-digit-millisecond reads at any size.Amazon ElastiCacheAWSAWS’s managed Valkey, Redis OSS and Memcached, as node-based clusters or a serverless cache.Amazon MemoryDBAWSA Valkey- and Redis-compatible database that keeps everything in memory but loses no acknowledged write.FoundationDBOpen sourceAn ordered, distributed key-value store with strictly serializable ACID transactions across the whole cluster, built as a small core that other databases are layered on.RedisOpen sourceAn in-memory data-structure server: the default cache, and also queues, counters and leaderboards.RocksDBOpen sourceThe embedded key-value engine Facebook forked from LevelDB: an LSM tree in a C++ library that many databases and stream processors use as their storage layer.ValkeyOpen sourceThe Linux Foundation’s BSD-licensed fork of Redis 7.2.4: an in-memory key-value server that Redis clients can talk to unchanged.Workers KVCommercialCloudflare’s global key-value store that keeps data in a few central stores and caches it in the data centers where it is read, so reads are fast and writes take up to a minute to show up everywhere.

How it fits with other technologies

Start a server, then store and read a value with the text and meta protocols · bash

# 4 GB of cache, 4 worker threads, TCP only (UDP is off by default since 1.5.6)
memcached -m 4096 -t 4 -p 11211 -U 0 &

# set <key> <flags> <ttl seconds> <bytes>, then the data
printf 'set user:42 0 300 14\r\n{"name":"Ada"}\r\nget user:42\r\n' | nc -q1 localhost 11211
# STORED
# VALUE user:42 0 14
# {"name":"Ada"}
# END

# the same read with the meta protocol: ask for remaining TTL (t) and value (v)
printf 'mg user:42 t v\r\n' | nc -q1 localhost 11211

# optional: keep keys in RAM, push large values to a 64 GB file on NVMe (extstore)
memcached -m 4096 -o ext_path=/mnt/nvme/extstore:64G

See it in a real stack

No architecture uses Memcached yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2003–2024

In 2003 LiveJournal ran on about 70 machines for 2.5 million accounts, and its databases were the bottleneck. Brad Fitzpatrick wanted to cache more on the web servers, but each of the 30 to 50 mod_perl processes per server had its own memory, and caching in every process on 40-plus machines would have duplicated the same data everywhere. He noticed the network had plenty of spare memory and wanted one big hash table that every process on every machine could use. He wrote a prototype in Perl, found it slow and bloated, and rewrote it in C as a single-threaded, event-driven daemon on libevent. The first commit is from May 2003.

The design was deliberately small. The client hashed each key to pick a server, and each server was an ordinary hash table with an LRU that never talked to the others. By 2004 LiveJournal ran 28 instances on ten hosts, caching its most popular 30 GB with a hit rate around 92%, and Slashdot and Wikipedia used it too. Facebook adopted it and pushed it furthest, making it multithreaded and contributing that work back; its 2013 paper describes billions of requests per second.

AWS made it a managed service with ElastiCache in 2011. After Redis changed its licence in 2024, the clouds backed the BSD-licensed Valkey fork; AWS now prices serverless Valkey 33% below Memcached, and Google is retiring Memorystore for Memcached in favour of Valkey. Memcached itself is still maintained, with dormando by far its most active contributor, and has gained extstore for flash, warm restarts, the meta protocol and a built-in proxy.

Why it’s built this way

Servers that don’t know about each other
Treating servers as buckets in a client-side hash table needs no replication or cluster protocol. Fitzpatrick judged that a dead node only means a few extra cache misses, which a large enough pool absorbs.
A slab allocator instead of malloc
Early versions used glibc’s malloc and, in Fitzpatrick’s words, fell on their faces after about a week from fragmentation. Fixed-size chunks in 1 MB pages keep memory use predictable.
Event-driven C on libevent
The Perl prototype couldn’t handle many connections. libevent picks epoll or kqueue at runtime, so one process can serve thousands of connections in O(1) time per operation.
Forgetting is a feature
Memcached is meant to hold a copy of data that lives elsewhere. Evicting least recently used items and expiring keys after a TTL keep it simple and fast; the docs advise against replication because it halves the usable cache.

Timeline

  1. 2003

    Brad Fitzpatrick writes memcached for LiveJournal

  2. 2004

    Linux Journal article: LiveJournal, Slashdot and Wikipedia use it

  3. 2009

    1.4.0 adds the binary protocol

  4. 2011

    AWS launches ElastiCache, a managed Memcached service

  5. 2013

    Facebook publishes “Scaling Memcache at Facebook” (NSDI)

  6. 2017

    1.5.4 adds extstore for keeping values on flash

  7. 2024

    Redis changes licence; the clouds back Valkey, and Memcached’s managed options start to shrink

Sources17 · facts checked 6 October 2026

Improve this page on GitHub