tidwall/pogocache: a C cache server that speaks Memcache, RESP, HTTP and Postgres

What Pogocache solves, and who it is for

Pogocache is caching software, not a database. The README describes it as "Fast caching software built from scratch with a focus on low latency and cpu efficency." The problem it targets is narrow and concrete: a cache that answers requests quickly while spending few CPU cycles per request, so the machine serving the cache costs less to run. That framing matters because the alternative is not only about raw speed. A cache that burns fewer cycles per request leaves headroom on the same instance, and the README's own benchmark table lists a CPU cycles column alongside throughput and latency.

The intended user is an engineer who already runs a key-value cache in front of an application and wants to swap the server without rewriting the client. Pogocache supports the Memcache, Valkey/Redis, HTTP and Postgres wire protocols, so the README points to system tools such as curl and psql and to client libraries that already exist for those protocols. If your application code talks RESP to Redis today, the server side can change while the client side stays put.

The second audience is different. The README offers an embeddable mode: a self-contained pogocache.c file that can be compiled into existing software, bypassing the network and accessing the cache programmatically. That is for programs that want a cache inside the process rather than across a socket. These two modes pull in different directions, and the README presents them as options rather than recommending one.

How the server is put together, from the flags it exposes

The repository layout is small: a Makefile at the top level, plus deps/, src/ and tools/. The Makefile forwards most targets into src, which is where the C implementation lives. There is no runtime package manager or configuration file described in the README, so configuration happens through command line options.

The option list is the clearest view of the architecture. --threads defaults to 32, and --shards defaults to 4096. Those two numbers describe a design where the keyspace is split into many shards and requests are handled by a pool of threads. --maxmemory defaults to 80%, a percentage rather than an absolute size, and --evict defaults to yes, so the server will evict keys when it reaches that limit. --loadfactor defaults to 75 and controls the hashmap. --autosweep defaults to yes, which the help text describes as automatic eviction sweeps. --keysixpack defaults to yes and compresses keys.

On Linux, --uring defaults to yes, so io_uring is the default event mechanism there, with --quickack defaulting to no. --reuseport defaults to no, meaning the listener does not spread accepted connections across sockets by default. --tcpnodelay defaults to yes. --cas defaults to no, so compare and store is off unless enabled.

Persistence is opt-in: --persist takes a path and defaults to none. That is a deliberate boundary. Pogocache is presented as a cache, and the README does not describe it as a durable store. The --maxmemory default of 80% is a percentage of what, exactly, is not spelled out in the help text shown in the README, and that is worth resolving on your own machine before you size an instance.

Building Pogocache and making a first request

The README states that Pogocache is designed and tested on 64-bit Linux and macOS. Building is a single make invocation, which produces the pogocache program:

make

Running it with no arguments starts the server on localhost at 127.0.0.1 on port 9401. To accept connections from other machines, the README shows binding the listener to an accessible host address:

./pogocache -h 172.30.2.84

There is also a Docker image, run with no configuration:

docker run pogocache/pogocache

Once it is listening, the quickest first use is HTTP, because curl is already on most machines. A PUT stores a value and returns the body Stored:

curl -X PUT -d "my value" http://localhost:9401/mykey

A GET on the same key returns the value, and DELETE removes it:

curl http://localhost:9401/mykey
curl -X DELETE http://localhost:9401/mykey

The HTTP interface takes a ttl parameter in seconds, so a value can expire without a separate expiry command:

curl -X PUT -d "my value" "http://localhost:9401/mykey?ttl=15"

If you would rather stay on the Redis protocol, the README shows valkey-cli pointed at port 9401 with ordinary SET, GET and DEL commands. The same port serves psql for the Postgres protocol. That is the practical advantage of the multi-protocol design: you can smoke-test the server with tools you already have before you touch application code.

Where Pogocache is the wrong choice

The first limitation is the data model. Pogocache stores entries addressed by key, with optional TTL and conditional store flags nx and xx on the HTTP interface. The README describes no lists, sets, sorted sets, streams, pub/sub, Lua scripting or transactions. If your application depends on Redis data structures beyond strings, Pogocache is not a drop-in replacement no matter how compatible the wire protocol looks. Protocol compatibility and command compatibility are different things, and the README documents the commands it supports rather than claiming full parity.

The second limitation is durability. Persistence is off by default (--persist defaults to none), and the README does not describe replication, failover, clustering or a consistency model. Treat any data you cannot reconstruct as data you should not put in Pogocache. A cache that evicts at --maxmemory with --evict set to yes is doing exactly what a cache should, but that behaviour is incompatible with using it as a primary store.

The third limitation is platform. The README states the software is designed and tested on 64-bit Linux and macOS. Windows is not mentioned. Several options are Linux-specific: --uring is described as use uring (linux) and --quickack as use quickack (linux). Those flags will not mean the same thing on macOS.

The fourth is the benchmark claim itself. The README says Pogocache is faster than Memcache, Valkey, Redis, Dragonfly and Garnet, and the numbers in the comment block come from a specific machine, an AWS c8g.8xlarge running 8 threads. The README points to a separate benchmarks repository for more detail. A result measured on one instance type with one thread count is a starting point, not a guarantee for your workload, your value sizes or your network.

Pogocache and Redis-compatible servers: what actually differs

The closest alternatives are the servers Pogocache names in its own comparison: Redis, Valkey, Dragonfly and Garnet. The shared trait is that all of them accept RESP, the Redis serialization protocol, so a Redis client library can talk to any of them. The difference is in what sits behind that protocol.

Redis and Valkey are general-purpose data structure servers. Their value is the breadth of the model: lists, hashes, sets, sorted sets, streams, scripting, pub/sub. Pogocache does not attempt that breadth. Its README frames the project around latency and CPU cycles per request, and the option list reflects that focus with knobs like --shards, --loadfactor, --keysixpack and --autosweep. If you are using Redis as a message bus or a queue, Pogocache is not the tool.

Dragonfly and Garnet are also multi-protocol, multi-threaded reimplementations aimed at Redis compatibility. Pogocache's distinguishing move is the number of wire protocols it accepts at once: Memcache, RESP, HTTP and Postgres on the same server, plus an embeddable single-file mode. That combination is unusual. The HTTP interface means curl is a client. The Postgres interface means psql is a client. For debugging a cache from a shell, that lowers the barrier considerably compared with installing a Redis client.

The honest comparison is therefore not "which is faster" in the abstract but "which commands do you actually issue". If your command set is SET, GET, DEL and TTL, the multi-protocol surface is a real convenience. If it is not, the wire protocol support buys you nothing.

Security, licence and the cost of staying current

Pogocache ships with two security mechanisms documented in the README. TLS is enabled with --tlsport, plus --tlscert, --tlskey and an optional --tlscacert. Authentication is a single shared secret set with --auth, and the HTTP interface accepts an auth parameter. That is a shared password, not a user model with roles or per-key permissions. There is no mention of an ACL system. For a cache on a private network behind an application, that is often enough; for anything exposed more widely, it is a constraint you should weigh before deployment.

The licence is MIT, stated in the repository and in the README's license section. MIT is permissive: it allows use, modification and redistribution with the licence text retained. This is not legal advice, and the practical question for a company is the usual one about attribution and about whether any bundled dependencies under deps/ carry different terms. The README does not enumerate them.

On maintenance, the repository is not archived, and the last push was on 2026-08-05. Release 1.3.2 is dated 2026-08-14, following 1.3.1 in January 2026 and 1.3.0 in October 2025. The cadence visible in those three releases is not uniform, and the README does not publish a support policy or a compatibility guarantee between versions. Upgrade cost is therefore hard to estimate: there is no documented migration path, no deprecation list and no statement about whether the on-disk persistence format is stable across releases. If you use --persist, test the upgrade path on a copy before you move a production node.

Editorial conclusion

Adopt Pogocache when you want a small C cache server that answers on the Redis, Memcache, HTTP or Postgres wire protocols and you are willing to check the protocol coverage your client library actually uses before pointing production traffic at it. Skip it if you need a data model beyond keys and values, or if you need a managed service with a support contract. Verify first that the commands your application sends appear in the wire protocol documentation, that persistence and auth settings match your deployment, and that your own benchmark on your hardware reproduces the latency profile you need.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. tidwall/pogocache on GitHub