|
|
|
|
|
by avthar
594 days ago
|
|
Post co-author here. Really appreciate the feedback. Your point about HNSW being resource intensive is one we've heard. Our team actually built another extension called pgvectorscale [1] which helps scale vector search on Postgres with a new index type (StreamingDiskANN). It has BQ out the box and can also store vectors on disk vs only in memory. Another practice I've seen work well is for teams use to use a read replica to service application queries and reduce load on the primary database. To answer your third question, if you combine Pgai Vectorizer with pgvectorscale, the limitations around filtered search in pgvector HNSW are actually no longer present. Pgvectorscale implements streaming filtering, ensuring more accurate filtered search with Postgres. See [2] for details. [1]: https://github.com/timescale/pgvectorscale
[2]: https://www.timescale.com/blog/how-we-made-postgresql-as-fas... |
|
Cool to see the pgvectorscale stuff; it sounds like the approach for filtering is not dissimilar to the direction that the pgvector team are taking with 0.8.0, although the much-denser graph (relative to HNSW) may mean the approach works even better in practice?