Few weeks ago I posted on show HN about KiviDB which is a redis-compatible in memory database written in Rust. There were several questions about how it performs in terms of vector search, and we identified a few gaps in the engine that we have fixed with the new version release 1.2.0, trying to beat fastest vector databases out there (my earlier acceptance of this claim was that both vectors and their indices reside within memory which is much faster to read as compared to disks). I used their own harness, redis/vector-db-benchmark
The harness was same and I used the default flags, also included Dragonfly 2.0.2 as well, I provisions Azure VM D32ps_v5, which is arm based 32 core machine, and a load generator on the same vm.
It worked with filtered search, h-and-m dataset (105k vec, 2048-d) kividb had a recall of 4,478 qps at 100 cleints, with recall@10 of 0.998, which was 2.5x faster at the same recall for redis, p99 was 87ms.
But it was slow to ingest, at 1M vectors it 40s more. while 70s slower compared to dragonfly. and dragonfly consumed least memory.
I have compiled the results here, I know it might look too much sloppy, I had AI write it, but because so tht it wouldn't miss the details. github.com/kividbio/kividb/tree/master/benchmarks…
There were several other benchmarks that we ran, I had missed garnet in the benchmark report of the launch, but this it has been added as several folks asked about it, it did outperform kividb and we are working on to reduces no of instructions per SET GET commands, I am open to contributions and ideas if you have any. here is the dir with all the items: github.com/kividbio/kividb/tree/master/benchmarks…
And this is the previous thread I have been referring to news.ycombinator.com
Any tests that you would like me to perform or answer questions, I am happy to do so, cheers!
Mentions
Few weeks ago I posted on show HN about KiviDB which is a redis-compatible in memory database written in Rust. There were several questions about how it performs in terms of vector search, and we identified a few gaps in the engine that we have fixed with the new version release 1.2.0, trying to beat fastest vector databases out there (my earlier acceptance of this claim was that both vectors and their indices reside within memory which is much faster to read as compared to disks). I used their own harness, redis/vector-db-benchmark The harness was same and I used the default flags, also included Dragonfly 2.0.2 as well, I provisions Azure VM D32ps_v5, which is arm based 32 core machine, and a load generator on the same vm. It worked with filtered search, h-and-m dataset (105k vec, 2048-d) kividb had a recall of 4,478 qps at 100 cleints, with recall@10 of 0.998, which was 2.5x faster at the same recall for redis, p99 was 87ms. But it was slow to ingest, at 1M vectors it 40s more. while 70s slower compared to dragonfly. and dragonfly consumed least memory. I have compiled the results here, I know it might look too much sloppy, I had AI write it, but because so tht it wouldn't miss the details. github.com/kividbio/kividb/tree/master/benchmarks… There were several other benchmarks that we ran, I had missed garnet in the benchmark report of the launch, but this it has been added as several folks asked about it, it did outperform kividb and we are working on to reduces no of instructions per SET GET commands, I am open to contributions and ideas if you have any. here is the dir with all the items: github.com/kividbio/kividb/tree/master/benchmarks… And this is the previous thread I have been referring to news.ycombinator.com Any tests that you would like me to perform or answer questions, I am happy to do so, cheers!