The 150-second stall we found in our own benchmark
CDEDUP works — and at 1,340 vectors it froze the whole server for 150 seconds in our harness. Here's the honest finding, why it happens, and what it means for how you should run dedup.
Most of this blog is Crowkis winning. This post is Crowkis losing a benchmark, on purpose, in public — because the harness found a real ceiling and burying it would make every other number less trustworthy.
CDEDUP runs semantic deduplication: it finds cache entries that mean the same thing and collapses them, reclaiming memory. It works correctly. But on a loaded instance — about 1,340 vectors — it took roughly 150 seconds to complete, and because it runs on the single-writer actor, the entire server was blocked for that whole time. Every other command waited in line behind it.
CVECCOUNT and CINFO are instant; CDEDUP is ~150,000 ms and blocks the actor throughout.
The root cause is the same actor design that makes isolation bulletproof: a long-running maintenance command shouldn't share the lane with live traffic. The bounded, batched dedup path improves this — capping how much one pass does — but the honest operational guidance today is simple: treat CDEDUP as scheduled maintenance, run it off-peak, and don't wire it into a hot loop.
We scored CDEDUP 3 out of 10 in our own report. A vendor's benchmark that never embarrasses the vendor is a brochure.
Publishing this costs us a clean scorecard and buys us the thing that actually matters: when we tell you correctness is 9/10 and isolation never leaks, you have a reason to believe it, because you've watched us mark our own homework with a red pen.