4 ms·

How does this compare to duckdbs vector capabilities (vss extension)?

• jgalt212 8mo ago
  Yes, nothing on that or sqlite-vec (both of which seem to be apples to apples comparisons). https://zvec.org/en/docs/benchmarks/ https://zvec.org/en/docs/benchmarks/
  • mceachen 8mo ago
    I maintain a fork of sqlite-vec (because there hasn't been activity on the main repo for more than a year): sqlite-vec is great for smaller dimensionality or smaller cardinality datasets, but know that it's brute-force, and query latency scales exactly linearly. You only avoid full table scans if you add filterable columns to your vec0 table and include them in your WHERE clause. There's no probabilistic lookup algorithm in sqlite-vec.
    • luoxiaojian 8mo ago
      You're absolutely right—sqlite-vec currently only supports brute-force search, and its latency does scale linearly with dataset size. We did some rough comparisons using its benchmark tools: on the SIFT dataset, latency was around 100ms; on GIST, it was closer to 1000ms. In contrast, with zvec's HNSW implementation, we get ~1ms latency on SIFT and ~3ms on GIST, while achieving recall@100 of 99.9% on SIFT and 97.7% on GIST.
      • mceachen 8mo ago
        FWIW "You're absolutely right" broadly declares "a human is not piloting the keyboard"
        • jgalt212 8mo ago
          You are undoubtedly correct!
  • luoxiaojian 8mo ago
    You're right that we didn't include sqlite-vec in our initial benchmarks—apples-to-apples comparisons are always better. I've actually added basic zvec tests to my fork of sqlite-vec (https://github.com/luoxiaojian/sqlite-vec https://github.com/luoxiaojian/sqlite-vec), so feel free to give it a try. We'll also be publishing a more complete performance comparison in an upcoming blog post—stay tuned!