Crowkis vs Dragonfly, Valkey, and KeyDB: faster exact-matching is still exact-matching
The new Redis-compatibles race each other on throughput. On LLM traffic they all hit the same wall at full speed: the keys never repeat.
Dragonfly, Valkey, and KeyDB are genuinely impressive engineering — multithreaded cores, modern memory layouts, benchmark charts that embarrass their ancestors. If your bottleneck is operations per second on exact keys, they're worthy upgrades. But speed multiplies hit rate, and on LLM traffic the exact-match hit rate is approximately zero. A million misses per second is still a miss.
This is the uncomfortable structural truth of the Redis-compatible race: they compete on how fast they can do the matching model that LLM workloads break. Paraphrase arrives, bytes differ, miss fires, model bills. No amount of multithreading touches the actual problem, because the problem is in the comparison, not the throughput.
Fast misses are still misses.
Crowkis took the other fork: keep RESP compatibility (your clients connect to any of these, and to us, unchanged) but rebuild the matching brain — embeddings, templates, intents, confidence, trust. A 0.4ms semantic hit beats a 0.04ms miss by exactly the price of one model call, which is to say: by everything.
The bottom line
Pick your fast exact-match engine for exact-match jobs; they're all good. For the traffic where meaning repeats but spelling doesn't, throughput was never the metric. Hit rate is. That's the race Crowkis entered.