Chroma
futomaki.chroma
A Docker Compose file for Chroma alone, generated from the catalog and checked by the safety inspector. No account needed.
Vector database aimed at retrieval-augmented applications, storing embeddings alongside their source text and metadata and answering similarity queries with metadata filters applied.
Chroma organises embeddings into collections, each holding vectors together with the originating text and arbitrary metadata, so a query returns usable documents rather than bare identifiers to be resolved elsewhere. It can invoke an embedding function itself, which lets text be added and queried directly without a separate embedding step in application code. Queries combine nearest-neighbour search with metadata predicates and keyword filtering in one call. In server mode it persists to disk and answers over HTTP, which is the form used here; the same API is available in-process for local development.
You know it worked when
- The server answers its heartbeat endpoint.
- A collection can be created and appears in the collection listing.
- Documents added to that collection are returned by a similarity query.
- A query carrying a metadata filter returns only matching documents.
- Collections are still present after a container restart with the data directory persisted.
Known sharp edges
- The data directory must be a persistent volume or every collection is lost when the container is recreated.
- Embeddings written with one model cannot be queried meaningfully with another, so changing embedding models means rebuilding the collection.
- Authentication is off by default and any client reaching the port can read or delete collections.
- The index is memory-resident and grows with collection size, so query latency degrades sharply once a collection no longer fits.