Good article - the most use cases i see of pg_vector are typically “chat over their technical docs”
- small corpus
- doesn’t change often / can rebuild the index
- no multi-tenancy avoids much of the issues with post-filtering
Chroma implements SPANN and SPFresh (to avoid the limitations of HNSW), pre-filtering, hybrid search, and has a 100% usage-based tier (many bills are around $1 per month).
> Supabase/pgVector needs lots of resources when adding new rows to the index -> wish the resources scale up/down automatically. Instead of having to monitor and switch to the next plan.
Many ways potentially - but one way is Chroma makes all this pain go away.
We're also working on some ingestion tooling that will make it so you don't have to scale, manage or run those pipelines.
The main reason we have seen people switch from Qdrant to Chroma is for operational simplicity and reliability. With Qdrant you have to size nodes, manage sharding, be oncall, etc - with Chroma there is literally 0 config or operational pain. Search, that just works!
your customers might have heard of RAG (retrieval augmented generation) before. chroma powers the “R” in RAG. It enables language models to dynamically pull in information to help them answer questions and solve tasks.
if you want or need to optimize for speed, cost, scalability or accuracy.
dedicated solutions have more advanced search features enable more accurate results. search indexing is resource intensive and can contend for resources with postgres/redis. the cost and speed benefits are naturally more pronounced as data volume scales.
for example - chroma has built in regex+trigram search and copy-on-write forking of indexes. this feature combo is killer for the code-search use case.