Postgres extension complements pgvector for performance and scale
139 points by flyaway123
by ricw
2 subcomments
I’ve been using this since early this year and it’s been great. It was what convinced me to just stick to Postgres rather than using a dedicated vector db.
Only working with 100m or so vectors, but for that it does the job.
Worth noting that the filtering implementation is quite restrictive if you want to avoid post-filtering: filters must be expressible as discrete smallints (ruling out continuous variables like timestamps or high cardinality filters like ids); filters must always be denormalized onto the table you're indexing (no filtering on attributes of parent documents, for example); and filters must be declared at index creation time (lots of time spent on expensive index builds if you want to add filters). Personally I would consider these caveats pretty big deal-breakers if the intent is scale and you do a lot of filtering.
by jascha_eng
1 subcomments
Combined with our other search extension for full text search these two extensions make postgres a really capable hybrid search engine: https://github.com/timescale/pg_textsearch
by isoprophlex
0 subcomment
The linked blogpost is an interesting read, too, comparing well-tuned pgvector to pinecone:
does this actually fix metadata filtering during vector search? that's the thing that kills performance in pgvector. weaviate had the same problem, ended up using qdrant instead
Hacker News