Sie haben ein RAG-System erstellt. Dokumente rein, Embeddings erzeugt, Ähnlichkeitssuche liefert relevante Chunks. Es funktioniert. Dann wächst Ihr Datensatz von 100 auf 100.000 Dokumente. Die Suchlatenz bläht sich von 200 ms auf 8 Sekunden auf. Die Chroma-Instanz, die Sie auf Ihrem Laptop hochgefahren haben, kann nicht skaliert werden. Nun fragen Sie sich: Brauche ich wirklich eine dedizierte Vektordatenbank, oder ist das nur ein Verkaufsgespräch?
Was eine Vektordatenbank wirklich tut
Trennen wir Hype von Funktion. Eine Vektordatenbank ist ein spezialisiertes System, das für eine Aufgabe optimiert ist: das Speichern hochdimensionaler Vektoren (Embeddings) und das Zurückgeben der k ähnlichsten Vektoren zu einer Abfrage in Millisekunden. Das war’s. Keine Transaktionen. Keine komplexen Joins. Keine ACID-Garantien. Nur schnelle Nearest-Neighbor-Suche im großen Maßstab.
Standard-Relationale Datenbanken können Vektoren speichern. PostgreSQL hat die pgvector-Erweiterung. Sie funktioniert. Aber „funktioniert“ und „funktioniert gut im großen Maßstab“ sind zwei verschiedene Dinge. Eine PostgreSQL-Abfrage, die 10 Millionen Embedding-Vektoren mit Brute-Force-Kosinus-Ähnlichkeit scannt, dauert 2–5 Sekunden. Eine Vektordatenbank auf demselben Datensatz liefert Ergebnisse in 50–200 ms. Der Unterschied liegt im Algorithmus – Vektordatenbanken verwenden Indexstrukturen (HNSW, IVF, DiskANN), die speziell für die ungefähre Nearest-Neighbor-Suche ausgelegt sind, nicht für exakte Übereinstimmungen.
Übersetzung: Wenn Sie weniger als 50.000 Embeddings haben und eine Latenz von unter 500 ms akzeptabel ist, brauchen Sie das nicht. Wenn Sie Millionen von Vektoren, Produktionsverkehr und Benutzer haben, die auf Suchergebnisse warten, dann schon.
Pinecone vs. Weaviate vs. ChromaDB: Die echten Kompromisse
Pinecone: Serverless, vollständig verwaltet, nur Cloud. Sie senden Vektoren per API. Pinecone kümmert sich um Skalierung, Replikation, Backups. Null Infrastruktur. Kosten: 0,25–1,50 $ pro 1 Million Vektoren pro Monat, plus 0,04 $ pro 1.000 Abfragen. Gut für: Teams, die keine Datenbanken verwalten möchten. Einschränkungen: Vendor-Lock-in, keine lokale Entwicklungsversion, langsamer als selbst gehostete Alternativen aufgrund von Netzwerklatenz.
Weaviate: Open-Source, selbst gehostet oder verwaltete Cloud-Version. Sie betreiben die Datenbank (auf Ihren Servern oder Weaviate Cloud). Volle Kontrolle über Bereitstellung, Datenresidenz, Skalierung. Integrierte Unterstützung für Hybrid-Suche (Vektor + Stichwortfilterung). Besser für: Teams mit spezifischen Compliance-Anforderungen, Präferenz für Open-Source oder vorhandener Kubernetes-Infrastruktur. Kompromiss: Sie verwalten Upgrades, Backups und Skalierung selbst. Die Latenz ist geringer als bei Pinecone, da Abfragen nicht über das Internet laufen.
ChromaDB: Leichtgewichtig, Open-Source, für Prototyping entwickelt. Läuft In-Process (kein Server) oder als eigenständiger Dienst. Speichert Daten lokal oder in Cloud-Speicher. Am besten für: Experimente, kleine Datensätze (unter 100.000 Vektoren), Entwicklungsumgebungen. Nicht produktionsreif im großen Maßstab – die Latenz verschlechtert sich schnell über 500.000 Vektoren hinaus, und die verteilte Abfrageunterstützung ist begrenzt.
Echte Zahlen: In einem Benchmark-Test mit 1 Million OpenAI-Embeddings (1536 Dimensionen) lieferte Pinecone Ergebnisse in ~120 ms, Weaviate selbst gehostet in ~80 ms, ChromaDB in ~600 ms. Die Netzwerklatenz zur Pinecone-API fügt je nach Geografie 50–100 ms hinzu. Das spielt eine Rolle, wenn Sie mehrere Abfragen pro Benutzeranfrage durchführen.
Wann Sie absolut eine Vektordatenbank benötigen
Drei Szenarien:
- Skalierungs- + Latenzdruck: Mehr als 100.000 Embeddings + benutzerorientierte Suche, die in weniger als 500 ms abgeschlossen sein muss. PostgreSQL + pgvector funktioniert, ist aber nicht schnell genug.
- Hybrid-Suche: Sie müssen Vektoren vor der Ähnlichkeitssuche nach Metadaten filtern („Finde Dokumente, die X ähneln, aber nur aus dem Jahr 2024“). Vektordatenbanken verfügen über native Filterung. Dies in PostgreSQL zu tun, erfordert eine separate WHERE-Klausel, die die Indexoptimierung zunichte macht.
- Echtzeit-Updates: Sie fügen/entfernen ständig Dokumente. Pinecone und Weaviate unterstützen Upserts ohne vollständiges Re-Indizieren. Das Neuerstellen von ChromaDB- oder PostgreSQL-Indizes wird im großen Maßstab teuer.
Ein praktisches Setup: Wann was verwenden
Beginnen Sie mit ChromaDB, wenn Ihr Datensatz unter 10.000 Dokumente umfasst und die Latenz keine Rolle spielt. Stellen Sie es In-Process bereit, speichern Sie Vektoren in JSON und machen Sie weiter. Sie geben 0 für Infrastruktur aus und wissen sofort, ob Vektor-Suche Ihr Problem löst.
Wechseln Sie zu Pinecone, wenn Sie an eine dieser Grenzen stoßen: Sie benötigen eine Latenz von unter 200 ms, Ihr Datensatz wächst über 100.000 Vektoren hinaus oder Sie möchten keine Infrastruktur verwalten. Die Gebühr von 0,04 $ pro 1.000 Abfragen summiert sich im großen Maßstab, aber Sie bezahlen für Geschwindigkeit und verwaltete Zuverlässigkeit. Keine Index-Abstimmung, keine Kapazitätsplanung.
Wählen Sie Weaviate, wenn Sie bereits Kubernetes betreiben, Vektoren in Ihrem eigenen Cloud-Konto hosten müssen oder benutzerdefinierte Hybrid-Suchlogik benötigen. Sie tauschen Komfort gegen Kontrolle. Die Einrichtung dauert eine Woche. Skalierung erfordert Wartung. Aber Sie besitzen die Daten und die Latenz ist besser.
Die Code-Realität: Embedding-Speicherung
Hier ist, wie ein grundlegender Embedding- + Such-Workflow in ChromaDB (Entwicklung) vs. Pinecone (Produktionsmaßstab) aussieht:
# ChromaDB: Einfach, In-Process
import chromadb
from chromadb.utils import embedding_functions
client = chromadb.Client()
openai_ef = embedding_functions.OpenAIEmbeddingFunction(
api_key="your-key",
model_name="text-embedding-3-small"
)
collection = client.get_or_create_collection(
name="docs",
embedding_function=openai_ef
)
# Dokumente hinzufügen
collection.add(
ids=["doc1", "doc2"],
documents=["Inhalt A", "Inhalt B"]
)
# Suchen
results = collection.query(
query_texts=["Ähnlichen Inhalt finden"],
n_results=3
)
print(results['documents'][0])# Pinecone: Skalierbar, API-basiert
import pinecone
from openai import OpenAI
pinecone.init(api_key="your-key", environment="us-west-2-aws")
index = pinecone.Index("production-index")
client = OpenAI(api_key="your-key")
# Einbetten und speichern
docs = ["Inhalt A", "Inhalt B"]
embeddings = [
client.embeddings.create(
input=doc,
model="text-embedding-3-small"
).data[0].embedding
for doc in docs
]
# Upsert (aktualisieren oder einfügen)
vectors = [
("doc1", embeddings[0], {"text": docs[0]}),
("doc2", embeddings[1], {"text": docs[1]})
]
index.upsert(vectors=vectors)
# Suchen
query_embedding = client.embeddings.create(
input="Ähnlichen Inhalt finden",
model="text-embedding-3-small"
).data[0].embedding
results = index.query(
vector=query_embedding,
top_k=3,
include_metadata=True
)
for match in results['matches']:
print(match['metadata']['text'])
Die Chroma-Version ist 8 Zeilen lang. Pinecone erfordert API-Schlüssel, separat berechnete Embeddings und strukturierte Metadaten. Aber Pinecone skaliert auf Millionen von Vektoren ohne Leistungseinbußen. Chroma verlangsamt sich über 500.000 Vektoren hinaus merklich.
Tun Sie das heute: Testen Sie Ihre Skalierungsgrenze
Bevor Sie eine Datenbank auswählen, testen Sie ChromaDB mit Ihrer tatsächlichen Dokumentenanzahl. Messen Sie die Abfragelatenz bei 10.000 Vektoren, 100.000 und 1 Million (falls machbar). Legen Sie einen Latenzschwellenwert fest – vielleicht sind 300 ms für Ihre Benutzer akzeptabel, vielleicht auch nicht. Wenn ChromaDB diesen Schwellenwert erreicht, bevor Ihre Daten 500.000 Vektoren erreichen, haben Sie eine Antwort. Wenn es gut mit Ihrer erwarteten Datensatzgröße skaliert, bleiben Sie lokal. Das Geld, das Sie bei der Infrastruktur sparen, übertrifft Anbieterfunktionen, die Sie nicht benötigen.
