Benchmarking Postgres Vector Search Approaches: Pgvector vs. Lantern
1–8 of 8 posts
Re: Benchmarking Postgres Vector Search Approaches: Pgvector vs. Lantern
#2in summary it seems pgvector is faster where it counts
Re: Benchmarking Postgres Vector Search Approaches: Pgvector vs. Lantern
#3Really great to see how the different config parameters (m, ef_construction, ef_search) impact latency and recall.
Re: Benchmarking Postgres Vector Search Approaches: Pgvector vs. Lantern
#4Interesting blog! Makes me wonder what a comparison between Pinecone + ChromaDB + Pgvector would look like..
Re: Benchmarking Postgres Vector Search Approaches: Pgvector vs. Lantern
#5Does pgvector use parallel index build in this benchmark ?
Re: Benchmarking Postgres Vector Search Approaches: Pgvector vs. Lantern
#6Does pgvector use parallel index build in this benchmark ?
It does not! Would be interesting to try that!
Re: Benchmarking Postgres Vector Search Approaches: Pgvector vs. Lantern
#7in summary it seems pgvector is faster where it counts
Lantern argues that being able to create indexes quickly is useful for tuning the hnsw paramters.
Re: Benchmarking Postgres Vector Search Approaches: Pgvector vs. Lantern
#8If you'd like an alternate approach, txtai can store content in Postgres. This approach stores metadata/fields in the database and builds a Faiss/HNSW index alongside. The idea is to lean on two mature projects vs having to rewrite a full vector index implementation.
https://neuml.hashnode.dev/external-database-integration
https://github.com/neuml/txtai
Disclaimer: I'm the primary author of txtai