科技回声

If 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.<p><a href="https://neuml.hashnode.dev/external-database-integration" rel="nofollow">https://neuml.hashnode.dev/external-database-integration</a><p><a href="https://github.com/neuml/txtai">https://github.com/neuml/txtai</a><p>Disclaimer: I'm the primary author of txtai

Really great to see how the different config parameters (m, ef_construction, ef_search) impact latency and recall.

Interesting blog! Makes me wonder what a comparison between Pinecone + ChromaDB + Pgvector would look like..

in summary it seems pgvector is faster where it counts

Does pgvector use parallel index build in this benchmark ?

Really great to see how the different config parameters (m, ef_construction, ef_search) impact latency and recall.

Interesting blog! Makes me wonder what a comparison between Pinecone + ChromaDB + Pgvector would look like..

in summary it seems pgvector is faster where it counts

Does pgvector use parallel index build in this benchmark ?

Benchmarking Postgres Vector Search Approaches: Pgvector vs. Lantern

5 条评论

Benchmarking Postgres Vector Search Approaches: Pgvector vs. Lantern

5 条评论