Pinecone, Weaviate, Milvus, Qdrant oder Chroma: die richtige Vektordatenbank wählen

Alle Vektordatenbanken versprechen Geschwindigkeit, Skalierung und intelligente Suche, und die Werbetexte der Anbieter sind voller ähnlich klingender Phrasen. Einen Sieger im luftleeren Raum gibt es nicht. Die richtige Wahl hängt von der Datenmenge Ihres Teams ab, davon, wie viel Infrastruktur Sie betreuen wollen, und davon, was Ihre Suche leisten muss. Im Folgenden geht es um Pinecone, Weaviate, Milvus, Qdrant und Chroma: Jeder Marketingbegriff wird in Klartext übersetzt, und zu jeder Datenbank gibt es einen Hinweis, wo sie ihren Platz verdient.

Pinecone: nichts zu betreiben

Wählen Sie Pinecone, wenn Ihr Team überhaupt keine Infrastrukturarbeit will. Pinecone ist ein vollständig verwalteter Serverless-Dienst mit eingebauter hybrider Suche, die dichte und spärliche Suche kombiniert.

Verwaltet und serverless. Es gibt keine virtuellen Maschinen zu mieten oder zu konfigurieren und keine Shards, Replikate, Speichereinstellungen oder Knotenzahlen, um die man sich bei wachsenden Daten kümmern muss. Sie eröffnen ein Konto, holen sich einen API-Schlüssel und senden Daten. Das ist wertvoll, weil Vektorsuche CPU und Speicher verschlingt und der Eigenbetrieb berüchtigt fummelig ist. Serverless bedeutet, dass sich die Abrechnung nach tatsächlich genutztem Speicher und Abfragen richtet, während Pinecone das Backend selbstständig hoch- und herunterskaliert.

Native hybride Suche. Hier werden zwei recht unterschiedliche Ansätze verbunden:

• Dichte Suche ist semantisch. Modelle verwandeln Text in Embeddings, die Konzepte erfassen, sodass eine Anfrage nach „Katzenartige“ Dokumente findet, in denen „Katze“ steht.
• Spärliche Suche ist Schlüsselwortabgleich in der BM25-Tradition. Sie sucht nach exakten Zeichenketten wie Seriennummern, Fehlercodes oder Produkt-IDs wie SKU-8492X.

Jede hat einen blinden Fleck. Dichte Suche versteht die Absicht, ist aber hoffnungslos bei Exaktheit. Sie hält SKU-8492X womöglich für einen nahen Nachbarn von SKU-8492Y, was eine präzise Suche ruiniert. Spärliche Suche trifft exakte Tokens zuverlässig, weiß aber nichts über Kontext. Pinecone hält beide Vektortypen in einem einzigen Index und führt ihre Scores automatisch zusammen.

Warum null Aufwand zählt. Wenn Sie als Entwickler ein KI-Feature ausliefern, arbeiten Sie lieber an Anwendungslogik und Nutzererlebnis, als Datenbankadmin zu spielen, Parameter zu tunen oder um drei Uhr nachts geweckt zu werden, weil der Datenbank der RAM ausgegangen ist.

Der Haken. Lock-in und Kosten im Extrembereich. Pinecone ist Closed Source und nur als verwalteter Dienst verfügbar, Self-Hosting ist nicht möglich. Bei Milliarden von Abfragen mit hohem Durchsatz kann die SaaS-Rechnung teurer werden als der Eigenbetrieb eines Open-Source-Systems.

Weaviate: Embeddings und hybride Suche in einem Paket

Wählen Sie Weaviate, wenn Sie Schlüsselwort- und semantische Suche in einem System brauchen.

Eingebaute Vektorisierung. Weaviate übernimmt das Embedding für Sie. Sie schreiben keinen Code, der Text an OpenAI, Cohere oder Hugging Face schickt, die Vektoren einsammelt und selbst speichert. Sie übergeben Rohtext, und Module wie text2vec-openai oder text2vec-transformers erzeugen und aktualisieren die Vektoren im Hintergrund. Richten Sie Ihr Schema einmal mit dem gewünschten Modellanbieter ein, dann läuft die Embedding-Pipeline beim Einlesen und erneut bei der Abfrage, was Ihre Architektur stark vereinfacht.

BM25 plus Vektoren, nativ. Die Engine führt einen präzisen Schlüsselwortalgorithmus und eine semantische Suche gleichzeitig in einer Speicherschicht aus und verschmilzt alles zu einer einzigen Rangliste.

• Bei der Schlüsselwortsuche wird die Teilenummer ABC-123 nicht mit ABC-124 verwechselt, weil BM25 exakte Tokens abgleicht.
• Bei der Vektorsuche liefert „schlecht schlafen“ Dokumente über Schlaflosigkeit, weil die Bedeutung verstanden wird.

Jedes Objekt erhält einen invertierten Index für Schlüsselwörter und einen Vektorindex für die Bedeutung. Ein Parameter namens alpha, zum Beispiel alpha: 0.5, verschiebt die Gewichtung zwischen wörtlichen Schlüsselwörtern und abstrakter Bedeutung.

Warum ein System zählt. Bevor native Hybridunterstützung ausgereift war, betrieben Teams Elasticsearch für Schlüsselwörter neben einem separaten Vektorspeicher, synchronisierten Daten zwischen beiden und schrieben eigenen Code, um die Scores zu kombinieren. Weaviate nimmt diese Betriebslast ab, weil es beide Engines in einem ist.

Der Unterschied zu Pinecone. Das Deployment. Pinecone ist ausschließlich geschlossenes SaaS. Weaviate ist Open Source und cloud-nativ: als verwalteter Dienst (Weaviate Cloud Services), in Ihrer eigenen AWS- oder GCP-VPC oder komplett on-premises mit Docker oder Kubernetes. Diese Kontrolle darüber, wo die Daten liegen, wiegt bei Unternehmenssicherheit und Compliance schwer.

Milvus: gebaut für enorme Größenordnungen

Wählen Sie Milvus, wenn Sie Plattformen auf Enterprise-Niveau mit Milliarden von Vektoren bauen. Steht Pinecone für Einfachheit und Weaviate für Entwicklerkomfort, dann steht Milvus für rohe Infrastrukturskalierung und pure Leistung.

Verteilt und horizontal skalierend. Es ist kein Monolith, sondern ein Satz zustandsloser Microservices, aufgeteilt in Schichten:

• Query-Knoten lesen und suchen
• Daten-Knoten schreiben und nehmen Daten auf
• Index-Knoten bauen die Suchgraphen

Dieses Design bringt zwei Vorteile. Sie skalieren in die Breite, indem Sie günstigere Maschinen hinzufügen, statt auf eine größere, teurere aufzurüsten. Und die Teile skalieren unabhängig voneinander, sodass ein leselastiges Produkt wie eine Empfehlungsengine mit Millionen Nutzern nur Query-Knoten ergänzen und die Aufnahmekapazität unverändert lassen kann. Das hält die Kosten im Rahmen.

GPU-Beschleunigung. Distanzberechnungen über Milliarden hochdimensionaler Vektoren sind für CPUs eine Qual. Milvus bindet Beschleunigungsbibliotheken (NVIDIA RAPIDS, FAISS-GPU und Graphindizes wie CAGRA) ein, um diese Arbeit an GPUs abzugeben, die Tausende Matrixoperationen parallel ausführen. Das Ergebnis ist Latenz unter einer Millisekunde bei Datensätzen mit Dutzenden Milliarden Embeddings, wobei sich der Engpass von der Rechengeschwindigkeit zur Speicherbandbreite verschiebt.

Warum Größe der Kern ist. Ein Hobbyprojekt mit ein paar Tausend Dokumenten braucht das nicht. Milvus zielt auf Plattformen mit Milliarden von Vektoren und Terabytes an Daten. In dieser Größenordnung ersticken kleinere Datenbanken bei dem Versuch, alles im RAM zu halten. Milvus nutzt gestaffelten Speicher: heiße Daten im RAM oder auf SSD, kalte Daten in Objektspeicher wie S3 oder MinIO. Außerdem setzt es Vektorquantisierung ein, etwa 1-Bit-Kompression mit RaBitQ, um den Speicherbedarf um bis zu 70 % zu senken. Dazu kommt tiefe Kontrolle über Indexstrategien (HNSW, IVF-Flat, DiskANN), sodass Infrastrukturteams den Kompromiss zwischen Geschwindigkeit und Recall feinjustieren können.

Der Haken. Komplexität. Es ist ein stark verteiltes System auf Kubernetes, das von Etcd, S3 und Pulsar oder Kafka abhängt. Deployment, Monitoring und Wartung erfordern daher echten DevOps-Aufwand.

Qdrant: Kontrolle über Präzision und Geschwindigkeit

Wählen Sie Qdrant, wenn Kontrolle über Ranking und Latenz zählt. Es hat in der Produktion deutlich an Boden gewonnen, weil es auf Effizienz und feine Kontrolle setzt, während Pinecone auf Einfachheit, Weaviate auf Komfort und Milvus auf riesige Cluster setzt.

In Rust geschrieben. Qdrant wurde von Grund auf in einer Systemsprache gebaut, die für Speichersicherheit, Geschwindigkeit und das Fehlen eines Garbage Collectors bekannt ist. Das ist wichtig, weil Datenbanken in Java oder Go regelmäßig pausieren, um Speicher freizugeben, und diese Pausen unter hohem Durchsatz als plötzliche Latenzspitzen auftauchen, das berüchtigte p99-Problem. Ohne Collector liefert Qdrant stabile, vorhersehbare Antwortzeiten im Submillisekundenbereich, selbst unter hoher paralleler Last, und braucht oft weniger RAM und CPU als die Konkurrenz.

Dicht, spärlich und Metadaten zusammen. Multi-Vektor-Unterstützung ist nativ. Jeder gespeicherte Punkt kann enthalten:

• Einen dichten Vektor für den semantischen Kontext
• Einen spärlichen Vektor für exakte Schlüsselwörter
• Einen strukturierten JSON-Payload mit Metadaten wie userId, creationDate oder status

Viele Vektordatenbanken filtern nach Metadaten (etwa nur Dokumente, bei denen status == active) entweder nach der Vektorsuche, was die Ergebnisse verzerrt, oder davor, was die Abfrage verlangsamt. Qdrant baut strukturelle Indizes direkt auf dem Payload, sodass Schlüsselwortabgleich, semantisches Scoring und Filterung gemeinsam beim Durchlaufen des Vektorgraphen stattfinden.

Stellschrauben, die andere Systeme verstecken. Drei stechen hervor:

• Eigenes Scoring mit nativem Reciprocal Rank Fusion (RRF), sodass Sie genau festlegen, wie Schlüsselwort- und Vektorscores kombiniert werden.
• Quantisierungseinstellungen: Stimmen Sie Scalar Quantization (SQ) oder Product Quantization (PQ) ab, um etwas Genauigkeit gegen etwa viermal weniger RAM und schnellere Abfragen zu tauschen.
• Wo es läuft: als eine kleine Binärdatei, als verteilter Cluster oder als gehosteter Cloud-Dienst.

Chroma: der schnellste Weg zum Prototyp

Wählen Sie Chroma für lokale RAG-Prototypen und Experimente. Während Milvus und Pinecone auf Milliarden von Einträgen in der Cloud zielen, zielt Chroma ganz auf ein reibungsloses Entwicklererlebnis.

Eingebettet. Es läuft im selben Prozess und ist daher kein schwergewichtiger Hintergrunddienst wie MySQL oder ein Docker-Container. Es lebt in Ihrem Python-Skript oder Jupyter-Notebook. Das heißt: keine Verbindungsstrings, Datenbanknutzer, Firewalls oder Cloud-Instanzen. Der Einstieg ist wirklich so kurz:

import chromadb
# Start a local, persistent database on your hard drive
client = chromadb.PersistentClient(path="./my_local_db")
collection = client.get_or_create_collection("my_docs")
# Add raw text - Chroma handles the embedding automatically
collection.add(
    documents=[
        "Retrieval-Augmented Generation relies on good context.",
        "Chroma runs in-process."
    ],
    ids=["id1", "id2"]
)

Betreiben Sie es im flüchtigen Modus, komplett im RAM, wobei die Daten mit dem Ende des Skripts verschwinden, oder geben Sie einen Ordner an, um auf die Festplatte zu speichern.

Warum es sich für Prototypen eignet. Aus zwei Gründen. Erstens bringt es eingebaute Embedding-Funktionen mit, standardmäßig ein leichtgewichtiges lokales Modell, all-MiniLM-L6-v2. Normalerweise rufen Sie eine Embedding-API auf, warten auf die Vektoren und ordnen sie selbst zu, hier dagegen übergeben Sie Rohtext, und Chroma erledigt den Rest. Zweitens ist die Tool-Unterstützung hervorragend. In fast jedem Tutorial zu LangChain oder LlamaIndex ist Chroma der gewählte Speicher, sodass eine kopierte Beispiel-RAG-Pipeline es wahrscheinlich schon eingebaut hat.

Es ist erwachsen geworden. Chroma ist nicht mehr nur ein Prototyping-Werkzeug. Es bietet inzwischen multimodale Suche, hybride Suche aus dichten Vektoren plus BM25 und einen Client-Server-Modus (chroma run) für größere Mehrbenutzer-Setups.

Seine Grenze. Skalierung und Hochverfügbarkeit. Für ein geschäftskritisches System mit Milliarden von Vektoren, strengen Latenzzielen im 99. Perzentil und automatischem regionsübergreifendem Failover reicht ein lokales, dateibasiertes Design nicht aus. Wenn es darum geht, eine RAG-Idee mit ein paar Tausend oder Millionen Dokumenten auf dem eigenen Rechner zu testen, kommen Sie nirgends schneller in Gang.

Das Fazit

Die eine beste Datenbank gibt es nicht, nur die beste für Ihre aktuelle Phase. Ein üblicher Weg ist, mit Chroma zu prototypisieren und zu Qdrant, Weaviate, Milvus oder Pinecone zu wechseln, sobald Zuverlässigkeit auf Produktionsniveau nötig wird.