3 ms·
hey hn, supabase ceo here this is a response to a recent pgvector vs qdrant benchmark. As we mention in the post, we’re not trying to prove that pgvector is fa
by kiwicopple 3y ago
hey hn, supabase ceo here
this is a response to a recent pgvector vs qdrant benchmark. As we mention in the post, we’re not trying to prove that pgvector is faster than Qdrant. Our goal is to show that pgvector/postgres scales predictably for the workloads that most companies need.
We scale it to ~1800 requests per second with 91% precision in this set of benchmarks. Still, it could be better. Luckily there are quite a few features and improvements planned for v0.5.0 [0]:
- Adding HNSW: an index with better speed & precision than IVFFlat (at a higher memory cost)
- Product quantization: better storage for IVFFLAT, improving speed and recall
- Parallel index builds: building your IVFFLAT indexes will be much faster
[0]: pgvector v0.5: https://github.com/pgvector/pgvector/issues/27 https://github.com/pgvector/pgvector/issues/27
- egorr 3y agosupabase engineer here, would be happy to share details regarding our research and outcomes if you have any questions
- henry_pulver 3y agoHad a question about the "pre-warming" technique you used - why does this help? You say it helps with RAM utilization, but why? Does it just spin up the right number of probes up so the experiments don't include this extra cost of spinning up these probes? (apologies if this is a dumb question - I don't know enough about vector databases to know if this is a dumb question or not!)