Chroma, a vector store you can start with in one line

It starts in one line. Install it and you have a working vector store in the same process as your code, with no server, no container and no connection string, which means the distance between an idea and a running retrieval prototype is about ten minutes. For an engagement where you need to show something by Thursday, that matters more than any benchmark. The licence is Apache 2.0, so nothing about the core needs a procurement conversation. And the search surface is genuinely broader than the obvious alternative: dense vectors, sparse vectors and hybrid of the two, plus full-text and regular expression keyword search and metadata filtering at query time, all without assembling it yourself. Anyone who has bolted a separate keyword index alongside a vector index and then written their own rank fusion will recognise how much work that removes. Multi-modal retrieval across text, images and audio is there too, which is rare in something this easy to start.

The documentation does not state a scale limit, a throughput figure or a performance threshold anywhere, and that silence is the review. When you are deciding whether something survives a client's production load, the absence of published numbers means you will discover the ceiling yourself, in their environment, on their timeline. The embedded mode is the second problem, and it is the same problem as the first strength. Running in-process is why adoption is instant, and it is also why the move to client-server, and then to the managed cloud, is a real migration that lands precisely when the project is busiest and nobody has appetite for infrastructure work. Plan the exit at the start or inherit it later. And in a client who already runs Postgres, this is a second data system to deploy, back up, secure and explain, which is the pgvector argument running in reverse and it usually wins.

Spend an hour on Chroma if you need a retrieval prototype this week, or if you genuinely need hybrid and keyword search without building the fusion yourself. Skip it if the client already runs Postgres and the corpus is modest, because you would be introducing a system to operate in order to avoid an extension you could install. If you do start embedded, write down on day one what moving off it will cost.

pgvector when the client already runs Postgres and hybrid search is not the requirement. Qdrant when scale is the point.