Chroma: einfachste Vektor-Datenbank für Prototypen und Notebooks

Was ist Chroma?

Chroma (offiziell trychroma.com) ist eine Open-Source-Vektor-Datenbank unter Apache 2.0, gestartet 2022 von Anton Troynikov und Jeff Huber. Stand Mai 2026 ist Version 0.5+ aktuell. Chroma positioniert sich explizit als „die Vektor-DB für LLM-Anwendungen" und folgt einem Python-API-first-Ansatz: ein Pip-Install und drei Zeilen Code genügen, um eine Collection anzulegen, Dokumente zu speichern und semantisch zu suchen.

Die Architektur basiert auf DuckDB und Apache Arrow. Embeddings, Metadaten und Dokumenttext landen in einer DuckDB-Datei; der Vektor-Index läuft als HNSW auf Basis von hnswlib. Diese Wahl macht Chroma ungewöhnlich leichtgewichtig – eine Standalone-Installation braucht keinen Cluster, kein etcd, keinen Coordinator. Eine Datei auf der Disk reicht.

Chroma kann in drei Modi laufen: Embedded (in-process im Python-Prozess, kein Server), Client/Server (separater Chroma-Server via HTTP, mehrere Clients) und seit 2024 Chroma Cloud (Managed-Variante auf AWS und GCP). Der Embedded-Modus ist die häufigste Wahl in Notebooks und Prototypen – Chroma wird wie SQLite verwendet, ohne Netzwerk-Aufruf.

Die API ist Python-zentrisch, mit Client-Bibliotheken auch für JavaScript, Ruby und Java. Eine REST-API existiert, ist aber sekundär dokumentiert. Embeddings-Module sind eingebaut: OpenAI, Cohere, HuggingFace, sentence-transformers – wer keinen externen Provider will, lässt Chroma lokale Modelle wie all-MiniLM-L6-v2 ausführen.

Für CH-Treuhand- und KMU-Setups ist Chroma die richtige Wahl in einem klaren Profil: schnelle Prototypen, interne POCs, Notebook-getriebene Daten-Analysen, kleine on-prem-Installationen ohne Skalierungs-Anspruch. Wer über 1 Mio. Vektoren oder Multi-Tenant-Filter braucht, geht zu Qdrant oder pgvector.

Warum es wichtig ist

Der häufigste Grund, warum RAG-Projekte in Treuhandbüros scheitern, ist nicht die finale Architektur, sondern die fehlende erste Erfahrung. Bevor ein Buro entscheidet, ob es Qdrant, pgvector oder Weaviate produktiv betreibt, sollte ein Mitarbeitender eine Stunde Zeit haben, in einem Notebook 100 Mandanten-Belege zu vektorisieren und semantisch zu durchsuchen. Chroma reduziert die Eintrittshürde auf das Minimum.

Drei Eigenschaften machen Chroma für dieses Anfangsstadium wertvoll. Erstens: Setup-Aufwand. pip install chromadb genügt; keine Docker-Konfiguration, kein YAML, kein Port-Forwarding. Eine erste Collection mit eingebetteten OpenAI- oder lokalen MiniLM-Embeddings entsteht in unter 10 Minuten. Für einen Treuhänder, der das Konzept Vektor-DB im Selbststudium begreifen will, ist das der einfachste Weg.

Zweitens: integrierte Embedding-Module. Chroma kann Texte direkt akzeptieren und intern in Vektoren wandeln, mit OpenAI, Cohere oder lokalen sentence-transformers. Diese Bequemlichkeit spart den Bau einer eigenen Embedding-Pipeline – für Prototypen ein klarer Gewinn. Für Production-Setups verschiebt sich der Wert; dort ist Trennung zwischen Embedding-Service und Storage typisch besser.

Drittens: DuckDB-Persistenz. Die gesamte Collection ist eine Datei. Backup ist ein Kopier-Befehl. Migration zwischen Rechnern ist drag-and-drop. Wer mit Chroma einen Prototyp baut und feststellt, dass das produktiv nicht reicht, kann die Embeddings über die get-API auslesen und in Qdrant oder pgvector übernehmen – der Pfad ist gradlinig.

Für CH-Treuhand mit kleinen Datenmengen (z.B. eine interne Wissensbasis aus 5.000 Belegen oder eine Anleitungs-Sammlung mit 500 PDFs) reicht Chroma auch produktiv. Erst wenn Multi-Tenant-Trennung, höhere QPS oder Recall-Garantien gefordert werden, lohnt der Wechsel.

Wie es funktioniert

Die Python-API ist die Hauptoberfläche. Ein minimaler Workflow im Embedded-Modus:

import chromadb client = chromadb.PersistentClient(path="./chroma_db") collection = client.create_collection(name="belege", metadata={"hnsw:space": "cosine"}) collection.add(documents=["Rechnung Müller 200 CHF", "Quittung Tankstelle 80 CHF"], metadatas=[{"mandant": 42, "datum": "2026-03-15"}, {"mandant": 42, "datum": "2026-04-02"}], ids=["doc1", "doc2"]) results = collection.query(query_texts=["Müller Belege"], n_results=5, where={"mandant": 42})

Die add-Funktion akzeptiert wahlweise Rohtexte (Chroma berechnet Embeddings intern) oder fertige Embedding-Vektoren. Metadaten sind ein Dict pro Dokument; Filter über Metadaten werden mit where-Klausel formuliert.

Im Client/Server-Modus läuft Chroma als HTTP-Server: docker run -p 8000:8000 chromadb/chroma. Der Python-Client wechselt von PersistentClient auf HttpClient(host="chroma-server", port=8000) – der Rest des Codes bleibt identisch.

Filter sind ein wichtiger Punkt. Chroma unterstützt where-Filter über Metadaten ($eq, $ne, $gt, $gte, $lt, $lte, $in, $nin, $and, $or) und where_document-Filter über den Volltext ($contains). Aber: Chroma filtert post-K, d.h. der HNSW-Index liefert zuerst Top-K Vektoren, danach wird der Filter angewandt. Bei selektiven Filtern (z.B. „nur Mandant 42 von 200 Mandanten") führt das zu Recall-Verlust – die Top-K-Liste enthält zu wenige Mandanten-42-Treffer.

Workaround: pro Mandant eine eigene Collection. Das macht den Filter implizit auf Collection-Ebene und umgeht das post-K-Problem. Bei 200 Collections ist das im Embedded-Modus noch handhabbar; im Client/Server-Modus mit hoher Last wird Qdrant zur saubereren Wahl.

Backup im Embedded-Modus ist trivial: das Verzeichnis ./chroma_db wegkopieren. Im Server-Modus läuft Backup über das Storage-Volume; Snapshots gehen wie bei jeder DuckDB-Datei. Replication oder Multi-Region-Verteilung sind nicht vorgesehen.

Chroma in 5 Schritten produktiv

1. 01Modus wählen: Embedded für Notebooks und kleine Apps, Client/Server für Multi-User-Zugriff. pip install chromadb oder docker run chromadb/chroma.
2. 02Embedding-Funktion festlegen: lokal (sentence-transformers/all-MiniLM-L6-v2) oder Cloud (OpenAI, Cohere). Bei Cloud-Embeddings TIA für Drittland-Transfer.
3. 03Collections planen: bei < 50.000 Vektoren genügt eine Collection; bei Multi-Tenant pro Mandant eine, da Filter post-K laufen.
4. 04Ingestion: collection.add(documents=[...], metadatas=[...], ids=[...]) in Batches von 100-500. Metadaten-Felder klar definieren (datum, mandant, vertraulichkeit).
5. 05Backup einrichten: im Embedded-Modus per cron das Verzeichnis kopieren, im Server-Modus per Volume-Snapshot. Recovery: Verzeichnis zurückspielen, Service neu starten.

Wann Chroma einsetzen

Chroma passt für (a) Prototypen und POCs unter 1 Mio. Vektoren, (b) Notebook-Workflows in Datenanalyse oder Forschung, (c) eingebettete Tools, in denen kein separater DB-Server gewünscht ist, oder (d) interne KMU-Wissensbasen mit moderater Last und ohne strikten Multi-Tenant-Bedarf.

Konkrete Fälle: ein Treuhänder will eine eigene Wissensbasis aus Steuer-Wegleitungen, MwSt-Richtlinien und internen Anleitungen aufbauen – 5.000 PDF-Seiten, eine Person sucht, kein Multi-Tenant. Chroma im Embedded-Modus läuft auf dem lokalen Rechner, in Docker auf einem internen Server oder als App-Bundle. Setup: 2 Stunden inklusive Volltext-Suche und einfacher Web-UI.

Eine zweite Kategorie: Forschungs- oder Audit-Notebooks, in denen ein Datensatz einmalig vektorisiert und durchsucht wird. Chroma lässt sich in einem Jupyter-Notebook so verwenden wie pandas – keine Service-Verwaltung, keine Port-Konfiguration. Ergebnisse landen direkt im Notebook.

Dritte Kategorie: Demos und Schulungen. Wer Mitarbeitenden in 2 Stunden zeigen will, was Embedding und semantische Suche bedeuten, kommt mit Chroma ohne Detour ans Ziel.

Für reine SaaS-Pilotprojekte ohne Self-Host-Anforderung ist Chroma Cloud verfügbar; Stand Mai 2026 ist die Preisstruktur nutzungsbasiert. EU-Region ist noch nicht voll ausgebaut – für Mandantendaten ist die Self-Hosted-Variante daher die saubere Wahl.

Wann NICHT

Sobald die Datenmenge über 1-3 Mio. Vektoren liegt oder mehr als 100 gleichzeitige Anfragen erwartet werden, ist Chroma am Rand seiner Fähigkeiten. DuckDB als Backend bringt OLAP-Performance, ist aber nicht für hohen Mixed-Read-Write-Druck gebaut. Bei dieser Skala wechselt man zu Qdrant, Weaviate, Milvus oder pgvector mit HNSW.

Für strikten Multi-Tenant-Betrieb ist Chroma die falsche Wahl. Der Workaround über Collection-pro-Mandant funktioniert bis ca. 50-100 Mandanten – darüber wird die Collection-Verwaltung selbst zur Last. Qdrant skaliert hier sauberer, weil Filter im HNSW-Graph ausgewertet werden.

Wenn das Team Java- oder Go-zentrisch ist, ist Chromas Python-Fokus ein Reibungsverlust. Die JS/Java-Clients existieren, sind aber weniger ausgereift; Bug-Reports und Feature-Tickets adressieren primär die Python-API.

Für Production-Setups mit Compliance-Anforderungen (Audit-Trail, RBAC, fein granulierte Berechtigungen) fehlen in Chroma die üblichen Bausteine. Authentifizierung im Server-Modus existiert seit 0.5 als optionales Token-Schema, ist aber nicht so ausgereift wie bei Qdrant oder Weaviate.

Wer Hybrid-Suche (BM25 plus Dense) braucht, findet das in Chroma nicht eingebaut. Where_document mit $contains macht einen rudimentären Volltext-Filter, ist aber kein vollwertiger BM25-Score. Für Hybrid-Suche ist Weaviate, Elasticsearch oder pgvector-mit-tsvector die richtige Wahl.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. Chroma documentation – concepts, embedded mode, server mode · 2026-05
2. chroma-core/chroma – GitHub releases v0.5+ · 2026-05
3. Chroma Cloud pricing and regions · 2026-05
4. sentence-transformers – model documentation for local embeddings · 2026-04