Pogocache puts four wire protocols on one port and hides its benchmark table

The listener starts on loopback and remote access is one flag

Out of the box the server binds 127.0.0.1 on port 9401, so nothing else on the network can reach it. The documented way to change that is a single option:

./pogocache -h 172.30.2.84

The rest of the visible option list is short. There is a port flag, a unix socket file flag with no default, three levels of verbose logging, a thread count, a memory ceiling given as a percentage, an eviction switch, and a persistence file path:

Usage: pogocache [options]

Basic options:
  -h hostname            listening host                 (default: 127.0.0.1)
  -p port                listening port                 (default: 9401)
  -s socket              unix socket file               (default: none)
  -v,-vv,-vvv            verbose logging level

Additional options:
  --threads count        number of threads              (default: 32)
  --maxmemory value      set max memory usage           (default: 80%)
  --evict yes/no         evict keys at maxmemory        (default: yes)
  --persist path         persistence file

Two details deserve attention. The default of 32 threads is shown in help text captured on a Linux server with 32 CPUs, so whether that number is a constant or follows the host is left unstated. And nothing in that list configures a password, even though the HTTP interface accepts an auth parameter; binding to a routable address is presented without any mention of turning authentication on first.

The comparison table is inside an HTML comment

The README opens by claiming Pogocache is faster than Memcache, Valkey, Redis, Dragonfly and Garnet, and by calling it the cheapest in CPU cycles per request. The numbers behind those claims are in the source but not on the page. The whole table, from the cache names through the CPU cycle counts, sits between HTML comment markers, so a reader of the rendered repository sees only the two graph images that follow it:

Cache       Throughput  Latency     CPU Cycles
----------------------------------------------
redis           909837    447μs          11799
valkey         1331683    263μs          15751
dragonfly      1407584    255μs          14384
garnet         1548050    231μs          13396
memcache       2601306    191μs          13400
pogocache      3145960    111μs           6968

The caption says the figures come from 8 threads on an AWS c8g.8xlarge, which is worth pairing with the help text above, where the server's own thread default is 32. Whether the comparison was run with the default thread count is not stated. The separate claim of over 100M ops per second belongs to the embedded mode and comes with no method attached, while the table above is the server benchmark.

One port, four protocols, and an psql session with no output

The same listener answers four wire protocols, which is what lets valkey-cli, redis-cli, psql, curl and telnet all talk to one process. An ordinary HTTP store and fetch looks like this:

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

$ curl http://localhost:9401/mykey
my value

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

The RESP side covers the usual cache commands plus a few that are not in the standard Redis set, including MGETS, PURGE and SWEEP. The Postgres interface is described as the same command set, and the Memcache interface covers the text protocol from set and cas through incr/decr and flush_all.

What the examples do not show is the Postgres conversation. The valkey-cli session prints OK, the quoted value and an integer count for the delete, while the psql session shows only the commands:

psql -h localhost -p 9401
=> SET mykey 'my value';
=> GET mykey;
=> DEL mykey;

No result lines appear for any of the three, so a reader cannot tell from the README whether replies come back as Postgres rows, as RESP replies, or not at all.

The delete section opens with a copy of the store example

The protocol reference has small editing problems that show up when you follow it literally. The Delete entry subsection begins with a shell block that stores a value with curl and the comment store entry, which is a duplicate of the example printed two sections earlier, and only after that block does the DELETE request format appear. The subsection order is inconsistent as well: store and get present Params before Returns, while delete presents Returns first. The delete response line carries a typo, respone instead of response.

The same file has looser spelling in its first line, where cpu efficency is written with one f, and its table of contents links to Gettng started. One more sentence loses a word: the pointer to the full command reference reads for a complete list commands and examples. None of these break the server, but they are the kind of thing that makes a protocol reference harder to trust at the level of detail where a client integration lives, which is exactly the level this project otherwise serves well.

The Makefile has three targets and hands the rest to src

The top level build file is short enough to read in one screen:

default: all

test:
	tools/tests/run.sh

package:
	tools/package.sh

.DEFAULT:
	cd src && $(MAKE) $@

So a bare make falls through to all, which is redirected into src and made again there, and the repository's own scripts are reached by two named targets that both call shell scripts under tools. There is no install target and no clean target at the top level, which means a system wide install is left to whoever packages the binary. The same pattern shows up in the other build path:

make

builds the pogocache program, and running it with no arguments starts the server described above. The test entry point is a shell script rather than a makefile, so what it runs is not visible from the top of the tree, and the tree also carries a deps directory that the top level Makefile never mentions.

The embeddable claim is one file the tree never explains

The advertised alternative to running a server is to skip the network entirely and compile the cache into your own program. The README points at a single self contained pogocache.c for that, and attaches a speed figure of over 100M ops per second to the embedded mode. Two things are missing from that description. The file pogocache.c is never introduced: no section says where it comes from, which build step produces it, or how it relates to the src and deps directories at the top of the repository. The packaging target that might explain it is just a line in the Makefile calling a script under tools.

The second gap is measurement. The table in the README documents a server benchmark with a stated machine and thread count, while the embedded number carries neither, so the two figures are not comparable even though they appear in the same document. For anyone weighing the embedded path, the honest summary is that the claim exists, the file reference exists, and the mechanism connecting them does not.

A security section is promised in the contents and absent from the file

The table of contents promises a Security section with two subsections, TLS/HTTPS and Auth password. The auth parameter is real and already visible in the HTTP request tables, where it appears as an optional query parameter on store, get and delete alongside ttl, nx and xx. What is not in the file is the section itself. The README's Postgres discussion begins an example in Python using the psy client and ends in the middle of that sentence, and the Security entries come after it in the table of contents with nothing behind them here.

So the one part of this project where a careful reader most needs detail is the part that is not written in this file, while the parameters that touch it are documented. The platform line is equally short: Pogocache is designed and tested on 64-bit Linux and MacOS, and the Docker image is offered as the other route in.

docker run pogocache/pogocache

Editorial conclusion

Pogocache is a reasonable fit when you want one small C binary that speaks whichever client you already have, and an unreasonable fit if you need clustering, replication or a documented authentication story, since none of those appear here. Before you deploy it, three things are worth checking against your own setup: whether the 80 percent maxmemory default and the eviction switch match your memory budget, whether the loopback default is what you want when you bind to a routable address, and where the passwords come from, since the auth parameter is accepted by the HTTP interface but no option in the visible help text sets one. Version 1.3.2 was published on 14 August 2026, nine days after the last push to the repository on 5 August 2026, and the project is MIT licensed.

Frequently asked questions

Official sources

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