Memcached: Building the Development Tree and Running a First Cache

What problem the memcached tree solves, and who it is for

Memcached is a key/value cache store meant to sit in front of something slower, usually a database, and absorb repeated reads. The README describes it as "a high performance multithreaded event-based key/value cache store intended to be used in a distributed system." That single sentence sets the scope: values are opaque to the server, there is no query language, no secondary index, and no relational model. You put a key in, you get it back, or you miss.

The repository at memcached/memcached is the development tree, not a client library. It is written in C and builds a server binary. If you are an application developer who wants caching in PHP, Python, or Laravel, you do not build this tree at all; you install a client library that talks to a running server. The people who need this repository are the ones who compile, package, or operate the server itself: platform engineers, distribution maintainers, and anyone running memcached on hardware where the distro package is too old or built without TLS or the proxy.

That distinction matters because most search traffic around memcached is about client usage, while the repository is about the daemon. Reading the tree tells you how the server is assembled, which dependencies are optional, and what the build actually produces.

Event loop, threads, and why memcached never touches disk

The architecture visible in the repository is a multithreaded event loop on top of libevent. The top-level files give the shape of it: memcached.c holds the main program, assoc.c and hash.c implement the hash table that maps keys to items, items.c manages item allocation and eviction, and slab allocation lives in the cache and items code. The README is explicit that memcached does non-blocking network I/O but not disk, adding that it "should never go to disk, or you've lost the whole point of it."

That constraint is the design, not a missing feature. Every value lives in memory, so a restart empties the cache and the next requests fall through to the backing store. The README also warns that the -k (mlockall) option "might be dangerous when using a large cache," and advises making sure the memcached machines do not swap. Locking pages prevents the kernel from paging the cache out, but if you lock more than the machine can hold, you create pressure elsewhere.

Networking is handled by libevent, which is a hard dependency. libseccomp is optional and experimental, described as enabling process restrictions for better security and tested only on x86-64 architectures. OpenSSL is also optional and enables TLS support, with the README noting that pkg-config is needed to find openssl dependencies. Optional components change what the binary can do, which is why building from source is sometimes the only way to get TLS or the proxy on a given platform.

Building memcached from git on a Debian based system

The README gives two build paths. If you downloaded a release tarball, the standard autotools sequence applies. If you are working from the git tree, you first need autotools, automake, and libevent. On a Debian based system the README gives this command:

sudo apt-get install autotools-dev automake libevent-dev

After the dependencies are in place, the README walks through autogen, configure, make, and the optional test suite:

cd memcached
./autogen.sh
./configure
make
make test

The README states that this creates the binary in the same folder, so you run it directly:

./memcached

With the server running, the README suggests telnet as the quickest way to confirm it is up. The default port is 11211:

telnet 127.0.0.1 11211
stats

If you type stats at that prompt, you should see the server's counters returned as text. Two configure variants change the build: --enable-tls adds TLS support and requires OpenSSL's development packages, and --enable-proxy builds the memcached proxy. The proxy needs an extra step, because the README notes that some vendor dependency code is kept out of the tree:

cd memcached
cd vendor
./fetch.sh
cd ..
./autogen.sh
./configure --enable-proxy
make
make test

The repository also ships a docker-compose.yml that builds the tree on alpine, ubuntu, debian, arch, and fedora using Dockerfiles under devtools/. That file is for multi-platform build testing, not for running a production cache, and the README does not present it as a deployment recipe.

Where memcached is the wrong tool

The README's own framing rules out a set of use cases. There is no persistence story in the tree: values are in memory, and the README says it should never go to disk. If your workload cannot tolerate a cold cache after a restart, memcached is not the answer, and no configuration flag in the README changes that.

There is also no replication or failover described. The README calls it a cache "intended to be used in a distributed system," which means the distribution is the client's problem. Consistent hashing across several memcached servers is implemented in client libraries, not in this tree. If you want the server itself to replicate data between nodes, this is the wrong project.

The value model is another boundary. Memcached stores keys mapped to opaque values. There is no list, set, sorted set, or pub/sub channel in the README. Applications that need those structures will end up reimplementing them on top of string values, which is usually a sign to pick a different store.

Finally, the README's environment warning is worth taking literally. It says the -k option may be dangerous with a large cache and that the memcached machines should not swap. On a host where you cannot control swap, or where the cache is sized close to total RAM, running memcached without that discipline risks the machine rather than the cache.

Memcached vs Redis and Valkey: the difference is scope

The most common comparison is memcached against Redis, and Valkey now appears in the same searches because it is a Redis fork. The difference in approach is scope. Memcached is a single-purpose cache: a hash table in memory behind an event loop, with string keys and opaque values. Redis and Valkey are data structure servers, offering lists, sets, sorted sets, streams, and persistence options alongside caching.

That extra surface has a cost. A data structure server carries more code, more configuration, and more operational decisions than a cache whose README can say it never touches disk. If all you need is to memoize expensive query results for a few minutes, memcached's narrower surface is the feature, not a limitation. If you need a queue, a leaderboard, or a durable dataset, memcached cannot express those at all, and the choice is made for you.

A second practical difference is the client contract. Memcached's protocol is simple enough that the README's own smoke test is a telnet session issuing stats. Redis and Valkey clients tend to assume a richer command set, so migrating from one to the other is not a drop-in swap at the application layer, even though both are key/value stores in the broad sense.

The comparison with Valkey specifically is really a comparison with Redis, since Valkey continues that project's data model. The relevant question is not which is faster, which this repository does not claim, but whether your application needs structures and persistence or only a cache.

Maintenance, licence, and what an upgrade costs

The repository is not archived, and the last push was on 2026-09-11. The tree carries a ChangeLog and a NEWS file at the top level, which is where release history lives, and the README points to https://build.memcached.org/ for multi-platform regression testing status. There is also a .shipit file and a memcached.spec.in, indicating the project maintains its own release and packaging machinery.

The licence is BSD-3-Clause, and the repository contains separate licence files for bundled code: LICENSE.bipbuffer and LICENSE.itoa_ljust. That is a detail worth checking before you vendor the tree into a product, because those bundled components carry their own terms. This is a description of what is in the repository, not legal advice; if the distinction matters to your organisation, read the files.

Upgrade cost depends on how you installed it. If you build from git, you are tracking master, and the README's build sequence is short enough that rebuilding is cheap. If you use a distribution package, the version you get is the distribution's decision, and optional features such as TLS, seccomp restrictions, and the proxy may or may not be compiled in. The README also makes a support point that affects cost: it asks people to use the mailing list for questions because "github issues aren't seen by everyone." For security bugs it asks for private contact with a maintainer and describes a responsible disclosure process that ends in a fix release. Budget for that channel, not for a fast GitHub issue thread.

Editorial conclusion

Adopt memcached/memcached when you want a small, single-purpose key/value cache in front of a database and you are willing to build and operate it yourself; the tree is BSD-3-Clause, the last push was on 2026-09-11, and the README points at the mailing list rather than GitHub issues for questions. Do not adopt it if you need persistence, replication, or data structures beyond strings and blobs, because the README states memcached does non-blocking network I/O but not disk, and that going to disk defeats the point. Before you commit, verify three things: that libevent-dev is available on your target platform, that your client library speaks the same protocol version as the server you build, and that the machine will not swap, since the README warns the -k mlockall option can be dangerous with a large cache.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-3-Clause
3. memcached/memcached on GitHub
4. Project website
5. README