5 ms·
pg_embedding is based on a different approximate nearest neighbors algorithm - HNSW, which is generally considered - and studied - to be faster as well as more
by HammadB 3y ago
pg_embedding is based on a different approximate nearest neighbors algorithm - HNSW, which is generally considered - and studied - to be faster as well as more accurate than pgvectors IVF (ignoring a lot of nuance).
However pg_embedding serves the index out of disk, whereas most vector databases opt to serve the index out of memory, or delegate to mmap'ed files. HNSW is a graph-based algorithm, thus access patterns are random and this does not lend itself to disk based access. I'd expect pg_embedding to be slower than memory-resident indices due to this fact. Also in general with a postgres index, my concern would be scalability and resource isolation. It's convenient to colocate these things but ANN indices have very different CPU/Memory/Disk usage patterns than what you may need for just your relational data.
For example
Chroma -> Serves HNSW out of memory, persists to disk with a WAL.
Weviate -> Serves HNSW out of memory, writes HNSW graph search to WAL and uses that for durability.
Milvus -> Serves HNSW out of memory, supports partial mmap, also supports another algorithm called DiskANN which is optimized for SSD. It uses cloud storage with a shared-everything architecture for durability (a lot of nuance here.)
QDrant -> Has a WAL, supports memory and mmap'ed indices.
- roseway4 3y agoAs I mentioned elsewhere, there's more to vector database selection than raw performance: Developers leveraging their existing experience with Postgres, existing infrastructure investment (often in managed Postgres on AWS/GCP etc), and a single API into the vector store shared with other parts of their app (their ORM / DB layer). Many teams can also get away with good performance vs the fastest performance, given smaller index sizes and the other tradeoffs I mentioned. That said, I can imagine the pgvector folks precaching the new HNSW index support they're working on, as they do with their IVFFLAT index. * edited for the grammar gremlins
- HammadB 3y agoSure, I don't disagree that there is more to vector database selection than raw performance. Any technical decision is filled with many considerations. The commenter - thewataccount - asked about performance and I shared my intuition.
- nikita 3y agopgvector is working HNSW too. We have a blog post about it: https://neon.tech/blog/pgvector-meets-hnsw-index https://neon.tech/blog/pgvector-meets-hnsw-index
- nikita 3y agoWell it doesn't serve it from disk. It's persisted to disk and Postgres buffer cache keeps the working set in memory.
- HammadB 3y agoMaybe I am misunderstanding but the postgres buffer cache is LRU and will evict pages right? At times data may go to disk and then during serving it will have to be loaded into memory? So it is quite dependent on the size of your buffer cache as well as contention for that buffer cache. Also the cache access patterns will vary between these implementations and is worth considering.
- nikita 3y agoFor sure.