Hi HN, I built Eski over the last few months. It is a single-box in-memory store that speaks RESP, so existing Redis clients connect unchanged: strings, hashes, lists, sets, sorted sets, geo, bitmaps, HyperLogLog, streams, pub/sub, transactions, ACLs, RDB and AOF persistence, Lua scripting with Functions and the debugger, plus the memcached text protocol. The engine is Odin, the Lua runtime is the stock MIT C one, the licence is Apache-2.0. No replication, Sentinel or Cluster: it is the node, on purpose.

The part I want feedback on is the measurement. Four engines, one physical server core each, pinned container images, separate client cores, four repetitions per workload, a thermal and idle gate before every case, and every per-second series committed with the dataset. On a rented bare-metal Xeon E-2288G, Eski serves 5 to 12 percent more requests per second than Redis and Valkey at pipeline 1 and 1.77x at pipeline 16, with p99 at or below theirs in every workload. After filling ten million 64-byte keys it holds 113 bytes per key resident against 160 for Redis and 139 for Valkey; Dragonfly is leaner at 106. The README tables are generated from the committed dataset by a script that fails when they drift, and the whole run costs about a dollar of machine time to repeat.

The first server run was thrown away: an idle graphics driver on the box parked kernel work on the server core for twelve seconds every 35 seconds and stalled every engine. The harness now detects bound kernel threads on a role core and refuses the machine. I will write that up separately.

Code was never derived from Redis source. Valkey (BSD) was consulted for a handful of functions, each listed with its notice in THIRD_PARTY_NOTICES.md; everything else came from the documentation and black-box comparison against a reference container. Not affiliated with Redis Ltd.

Things I would like to hear about: workloads where it falls over, protocol corners I missed, and whether the method has a hole I have not seen.