Eight days ago I wrote about forty-nine queries a second — the first honest million-vector benchmark, and the mutex of mine that explained it. Today the same collection, same dataset, same VectorDBBench harness, measured through the public API like any customer would: 1,620 QPS at 0.9652 recall@100, serial p99 under 50ms. The numbers are on the benchmarks page with the raw output attached.
There was no single fix. It was eight days of finding the next owner of the next millisecond and evicting it: the dispatch serialization from the last post, a billing writer that had no business on the query path, a response-router that held a lock across an await and convoyed everything behind it, admission caps that were really latency knobs pretending to be throughput knobs. None of it was clever. All of it was measured before and after, which is the only reason I trust the sum.
My favorite failure of the week: the first "clean" full-path run came back at 1,434 QPS and declining above fifty concurrent clients, which looked for all the world like a saturation knee. It was not a knee. It was 7 gateway workers times a 200-requests-per-second-per-key token bucket — I had benchmarked my own rate limiter, almost to the digit. Raised the limit, reran: 1,620, dead flat from c100 to c200 while latency grows linearly. That's the signature of a system doing exactly what it can and queueing the rest, which is what you want to see. The limiter incident run is published too, because the difference between the two tables is a better lesson in benchmark skepticism than anything I could write.
What's left is physics, and I can show my work: at saturation every worker core spends its time walking a graph where each hop is a random read of a 3KB vector that isn't in cache. The kernels are vectorized (I checked the deployed binary's disassembly, because I didn't believe it either), the coordinator is under 1% busy, the queues are empty below the caps. The remaining levers are fewer bytes per hop and more cores — real work, not found money.
The part I actually care about: the collection serving those 1,620 QPS holds 1M×768d vectors and costs $17.14 a month at list price. The published VDBBench rows I compare against run on $832–$1,035-a-month configurations. They beat us on absolute throughput — Zilliz by 8×, and I say so on the benchmarks page — but per dollar it isn't close, and the recall band (0.9652 against Zilliz's 0.9588 best row) is the same neighborhood. You can rerun all of it: the harness is Zilliz's own open-source VectorDBBench, our client for it is public, and the API you'd hit is the one this page is served behind.