jeffchuber

then you are not agi pilled

If you are truly bitter-lesson pilled - give the agent all the tools and let it decide which to use.

- regex (grep) - hybrid search (bm25+vector)

this X vs Y is uninteresting when the answer can be both.

yeah (optional) caching is interesting to think about - incl write_through and write_back

last weekend I vibe-coded a project called `openfs` that plugs into just-bash

https://github.com/jeffchuber/just-bash-openfs

it puts a bash interface in front of s3, filesystem (real and in-memory), postgres, and chroma.

still very much alpha - but curious what people think about it.

see an example app here: https://github.com/jeffchuber/openfs-incident-app

try out chroma or better yet as opus to!

i didnt claim to invent it.

i claimed swyx heard it through me - which he did

that was me swyx

i support this

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).

Chroma is also apache 2.0 - fully open source.

congrats to factory on the amazing product and release!

chroma stores both

Hey there

Chroma is fully OSS - embedded, single-node and distributed (data and control plane). afaik lance distributed is not OSS.

We do have plans to release the crate (enabling embedded chroma in rust) - but haven't gotten around to it yet. Hopefully soon!

Do you see all providers converging on similar alpha i.e cheap object storage, nvme drives,ssd cache to solve this?

It's not only a new pattern in search workloads, but it's happening in streaming, KV, OLTP, OLAP, etc. Yea - it's the future.

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.

very fair!

cloud has been in private beta for a year now.

we chose to not release it to the public until we were extremely confident in the system and its characteristics.

databases are a serious business. developers trust us with their mission critical data.

no worries!

Chroma and Weaviate are both popular OSS projects, 21k and 14k stars respectively.

Weaviate has some features that Chroma does not (yet) - notably vector quantization. Weaviate is a single-node DB that can be run in cluster mode.

Chroma focuses on reliability and operational simplicity. The fully distributed architecture means there are no knobs to tune or config to set.

There's no right tool for everyone. Try both!

Qdrant team is also smart!

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!

thank you!

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.

can you tell me more about your use case?

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.

There is so much signal in job posts - excited to see this launch.

how could i forget!

of course!

going to be super confusing that there is now tigerdata and tigergraph - both database companies

https://x.com/jeffreyhuber/status/1732069197847687658

id be super curious to see if Chroma (written in Rust) can work better here!

This is still retrieval and RAG, just not vector search and indexing. it’s incredibly important to be clear about terms - and this article does not meet the mark.

the table with comparable models is a really great way to show off things here

enterprise GTM has its own set of challenges and needs and warrants someone really focused on it

I’m Jeff, co-founder of Chroma. We build the most popular open-source AI vector database. When people use Chroma, the first question they ask is which embedding model to use. This choice affects how your RAG application will perform in production.

We noticed that most people make their decisions based on popular benchmarks scores. However, widely used benchmarks like MTEB are often overly clean, generic, and in many cases, have been memorized by the embedding models during training. To address this, we introduce representative generative benchmarking—custom evaluation sets built from your own data and reflective of the queries users actually make in production.

We just published our in-depth technical report on this, and you can run a custom benchmark locally with the Chroma CLI.