Chroma: einfache Vektorsuche mit einem Haken

Chroma ist eine quelloffene Vektor-Datenbank unter Apache-2.0, die als eingebettete Bibliothek in einer Anwendung, als einzelner chroma-run-Prozess oder als Chroma Cloud läuft. Die Position dieses Tests ist einfach: Chroma ist die beste Voreinstellung für die erste Retrieval-Schicht eines RAG-Systems, weil die Reibung zwischen einem leeren Repository und einer funktionierenden Query nahezu null ist — und ein schlechter langfristiger Wohnsitz für einen ernsthaften Hybrid-Such-Stack, weil die interessanten Teile der Query-Sprache laut Dokumentation nur in der Cloud existieren.

Im Stack besetzt sie genau eine Position: Speicher und Retrieval für Embeddings. Sie konkurriert mit pgvector, wenn die Anwendung bereits Postgres fährt, mit Qdrant oder Milvus, wenn Retrieval einen eigenen Dienst braucht, und mit Pinecone, wenn niemand betreiben will. Chromas Alleinstellungsmerkmal ist nicht der Index, sondern die Bedienung: eine an die Collection gebundene Embedding-Funktion, eine Filtersprache ohne Index-Deklarationen und Clients für Python, TypeScript und Rust, die alle dieselben Verben sprechen.

Was es ist

Das Datenmodell hat drei Ebenen. Ein Tenant enthält Datenbanken, eine Datenbank enthält Collections, und eine Collection ist die Einheit von Speicher und Abfrage: Jeder Eintrag hat eine Id, ein Embedding und optional ein Dokument und ein Metadatenobjekt. Zugriffsrechte, Kontingente und Abrechnung sind auf Tenant-Ebene definiert, was für mandantenfähige SaaS zählt und in den meisten einzelnen Knoten still fehlt.

• Lizenz: Apache 2.0, rund 27.000 Sterne im GitHub-Repository und ein getaggtes Release 1.5.9 vom Mai 2026.
• Drei Betriebsmodi: eine eingebettete Bibliothek, ein einzelner Knoten und ein verteiltes Deployment, das Chroma Cloud betreibt.
• Drei Clients — Python, TypeScript und Rust — mit derselben Collection-, Add-, Query- und Get-Form, dazu einen asynchronen HTTP-Client.
• Vier Suchmodi in einer Collection: dichte Vektoren, sparse Vektoren, Volltext und Regex über Dokumente sowie Metadatenfilter.
• Embedding-Funktionen als Schnittstelle, sodass eine Collection beim Schreiben einbettet und query_texts keinen Modellaufruf im Anwendungscode braucht.
• Zwei Query-APIs: das klassische query und get sowie eine neuere Search API mit Ranking-Ausdrücken, verfügbar in Chroma Cloud.

Wie es funktioniert

Chroma überlässt die Dauerhaftigkeit Subsystemen, die es nicht neu erfinden muss: SQLite lokal und in der verteilten Cloud-Storage-Objektspeicher, wo heisse Daten in SSD-Caches liegen. Das Argument des Herstellers ist wirtschaftlich statt exotisch — Vektoren sind gross und Arbeitsspeicher ist teuer, deshalb macht die Quelle der Wahrheit im Objektspeicher zu einem Bruchteil der RAM-Kosten die Cloud-Preisliste erst möglich.

Was der Hersteller nicht veröffentlicht, ist ein öffentlicher Benchmark mit Methodik. Die Cloud-Dokumentation behauptet, produktive Systeme erreichten über 90 Prozent Recall und das Speicherkonzept mache Chroma Cloud um eine Grössenordnung günstiger als Alternativen; beides ist plausibel und nichts davon aus den Docs reproduzierbar. Behandle es als Startpunkt für die eigene Evaluation, nicht als Ergebnis.

Erste Schritte

Der eingebettete Client startet einen Server im Prozess und verliert beim Beenden des Programms alles, was genau richtig für einen Test und genau falsch für Produktion ist. Eine minimale Query braucht Client, Collection, Upsert und Query — ohne Server, ohne Container, ohne Index-Tuning.

import chromadb

client = chromadb.Client()
collection = client.get_or_create_collection("docs")

collection.upsert(
    ids=["d1", "d2"],
    documents=[
        "Refunds are issued within five business days.",
        "Support answers within one working day.",
    ],
    metadatas=[{"topic": "billing"}, {"topic": "support"}],
)

hits = collection.query(
    query_texts=["how fast is a refund?"],
    where={"topic": "billing"},
    n_results=1,
)

# Results are column-major: one list per query, one entry per result.
print(hits["documents"][0][0])

Drei Details in diesem Snippet verursachen später den grössten Teil der Reibung. Ergebnisse kommen spaltenweise zurück, jeder Verbraucher muss also parallele Arrays zippen, statt über Datensätze zu iterieren. n_results steht standardmässig auf 10, was auf einer kleinen Test-Collection still nichts Brauchbares liefert. Und der Filter gehört in where gegen Metadaten, während Textabgleich gegen das gespeicherte Dokument in where_document mit $contains oder einer Regex läuft.

Hybrid-Suche und die Cloud-Grenze

Die Search API ersetzt query und get durch einen zusammensetzbaren Ausdruck: Search baut Filter und Limit, Knn liefert ein Ranking, Rrf verschmilzt mehrere Rankings. Reciprocal Rank Fusion bewertet jeden Kandidaten als negative Summe aus Gewicht geteilt durch Glättungskonstante plus Rang, wobei k standardmässig 60 ist — deshalb funktioniert es über dichte und sparse Ergebnisse hinweg, ohne zwei unterschiedliche Score-Skalen zu normieren.

from chromadb import Search, K, Knn, Rrf

dense = Knn(
    query="how fast is a refund?",
    key="#embedding",
    return_rank=True,
    limit=200,
)
sparse = Knn(
    query="how fast is a refund?",
    key="sparse_embedding",
    return_rank=True,
    limit=200,
)

search = (
    Search()
    .where(K("topic") == "billing")
    .rank(Rrf(ranks=[dense, sparse], weights=[0.7, 0.3], k=60))
    .limit(10)
    .select(K.DOCUMENT, K.SCORE)
)

rows = collection.search(search).rows()[0]
for row in rows:
    print(row["score"], row["document"][:60])

Preise und Kosten pro Query

Chroma Cloud rechnet vier getrennte Zähler ab, und der interessante ist nicht der Vektorspeicher. Schreiben kostet 2,50 $ pro GiB, Speicher 0,33 $ pro GiB pro Monat, Queries 0,0075 $ pro TiB und Netzausgang 0,09 $ pro GiB zurückgegeben. Ein Starter-Plan kostet nichts pro Monat und enthält 5 $ Guthaben, zehn Datenbanken und zehn Teammitglieder; Team kostet 250 $ pro Monat mit 100 $ Guthaben, hundert Datenbanken, dreissig Mitgliedern und SOC II.

Der Rechner des Herstellers ist aufschlussreich. Bei 1536 Dimensionen und 8-KiB-Dokumenten über 500 Collections kosten eine Million Dokumente rund 34 $ zum Schreiben, sechs Millionen gespeicherte Dokumente rund 27 $ pro Monat und zehn Millionen Queries rund 19 $ — etwa 79 $ pro Monat für einen Korpus von sechs Millionen Chunks. Beachte die Richtung der Ökonomie: Aus 1 GiB Text werden rund 15 GiB Vektoren, der Speicher wird also auf der schnellst wachsenden Zahl abgerechnet, und ganze Dokumente statt kurzer Chunks zurückzugeben ist genau das, was den Netzzähler hochtreibt.

Selbst hosten: was tatsächlich läuft

Selbst hosten ist nicht ein einziges Szenario. Die Architekturdokumentation unterscheidet drei Modi mit unterschiedlichen Obergrenzen, und der Unterschied zwischen ihnen ist grösser, als die Begriffe nahelegen.

• Eingebettet: chromadb.Client() läuft im Prozess, hält Daten im Speicher oder auf einem lokalen Pfad und stirbt mit dem Programm. Gut für Tests, nicht für einen Dienst.
• Single Node: chroma run --path hinter einem HttpClient, dokumentiert für weniger als 10 Millionen Datensätze über eine Handvoll Collections. Dauerhaft, einfach, ein einzelner Ausfallpunkt.
• Verteilt: das Deployment, das Chroma Cloud betreibt, mit Objektspeicher-Persistenz und SSD-Caches, pro Datenbank an eine Region gebunden.
• Datenstandort: Chroma Cloud läuft in AWS us-east-1 und seit April 2026 in GCP europe-west1. Die Region wird bei der Erstellung fixiert, ein Umzug bedeutet eine neue Datenbank und ein Reindex.
• Compliance: Chroma Cloud ist SOC 2 Type II zertifiziert; kundenseitig verwaltete Verschlüsselungsschlüssel kamen im Dezember 2025, privates Networking im Januar 2026.

Wo es schwächelt

Die Schwächen kommen zuerst, weil sie die Entscheidung bestimmen. Hybrid-Ranking gibt es nur in der Cloud. Metadatenfiltering ist bequem statt justierbar, und ein langsamer Filter gibt dir keinen Index zum Nachjustieren. Die Ergebnisform ist spaltenweise, was jeden Verbraucher mit einer kleinen, dauerhaften Abgabe belastet. Und die Preisliste bestraft genau das Muster, das Retrieval-Augmented-Generation fördert: ein grosses Kontextfenster pro Query zurückzugeben.

Der Vergleich, auf den es ankommt, ist der mit pgvector. Liegt der Korpus bereits in einer Postgres-Tabelle und gehören die Vektoren in dieselbe Transaktion, ist ein eigener Vektorspeicher ein zusätzlicher Dienst, den man sichern, absichern und überwachen muss, für eine Fähigkeit, die Postgres bereits liefern kann — mit der harten Obergrenze von 2.000 Dimensionen für den Standardtyp vector und 4.000 in halber Genauigkeit. Chroma verdient seinen Platz, wenn Retrieval das Produkt ist: multimodale Collections, Regex über gespeicherten Dokumenten, Collection-Forking für Experimente und eine Embedding-Funktion, die einen Modellaufruf aus dem Anwendungscode nimmt.

Urteil

Chroma ist eine klug gewählte Voreinstellung mit einem bestimmten blinden Fleck. Die Bedienung ist echt: drei Clients, eine API, eine Filtersprache ohne Schema und ein Weg von import chromadb zum gerankten Ergebnis in etwa zehn Zeilen. Der blinde Fleck ist ebenso real: Die Query-Funktionen, die eine Demo von einem Retrieval-System unterscheiden, sind genau die, die du heute nicht selbst hosten kannst. Für eine erste Schicht ein vernünftiger Handel, für ein System mit langer Lebensdauer ein schlechter.

1. Nimm es, wenn die Retrieval-Schicht noch entworfen wird und der schnellste Weg zu einer messbaren Baseline am wichtigsten ist.
2. Nimm es, wenn Embeddings, Dokumente und Metadaten in einer Collection leben müssen und das Team von Anfang an mandantenfähig ist.
3. Nimm es für Prototypen, die später ersetzt werden; die Collection-API ist klein genug, dass ein Neuschreiben einen Tag dauert, kein Quartal.
4. Lass es weg, wenn Hybrid-Suche heute im eigenen Netz bleiben muss — die Search API ist dort nicht verfügbar.
5. Lass es weg, wenn der Korpus bereits in Postgres liegt und pgvectors Dimensionsgrenze nicht zubeisst.
6. Denk neu darüber nach, sobald der Korpus einige Millionen Chunks überschreitet und Single-Node-Grenzen greifen, oder wenn Egress pro zurückgegebenem GiB die Rechnung dominiert.

Quellen

1. Chroma Dokumentation: Einführung
2. Chroma: Architekturüberblick
3. Chroma: erste Schritte mit dem SDK
4. Chroma: Query und Get
5. Chroma: Metadatenfilter
6. Chroma Cloud: Search API Überblick
7. Chroma Cloud: Hybrid-Suche mit RRF
8. Chroma Cloud: Preise
9. Chroma Changelog