Schritt 05 von 22
Vektordatenbanken
Embeddings speichern und die nächstgelegenen in Millisekunden finden. Das ist das Gedächtnis, das deine Anwendung bei jeder Frage durchsucht. Kosten, Filterung und Betrieb zählen mehr als reine Geschwindigkeit.
Von Sheela · Geprüft am 23. Okt. 2026 · So testen wir
So triffst du die Wahl
- Schon auf Postgres mit überschaubarem Volumen: Mit pgvector bleibt es bei einer Datenbank im Betrieb.
- Starke Filterung, hybride Suche oder große Skalierung: eine eigene Engine wie Qdrant, Weaviate oder Milvus.
- Keine Server zu verwalten: ein gehosteter Dienst wie Pinecone, gegen monatliche Kosten.
Worauf du achten solltest
Die Fragen, die die Optionen unterscheiden, nach Wichtigkeit geordnet.
01
Qualität der gefilterten Suche
Echte Anfragen werden fast immer nach Berechtigungen, Mandanten-ID, Datum oder Dokumenttyp gefiltert, und die Ergebnisse müssen relevant bleiben, sobald der Filter greift. Engines, die nach der Vektorsuche filtern, können drei Ergebnisse liefern, wenn du zehn angefordert hast, oder stillschweigend den besten Treffer verpassen. Qdrant fügt für indexierte Payload-Felder Graph-Kanten hinzu, damit die gefilterte Traversierung verbunden bleibt; pgvector braucht iterative Scans (ab 0.8.0) oder Teilindizes. Teste mit deinem selektivsten echten Filter, nicht mit einer ungefilterten Demo.
02
Hybride Suche: Vektoren plus Stichwörter
Vektoren übersehen Namen, Kennungen und exakte Begriffe wie Produktcodes und Fehlermeldungen; die Stichwortsuche (BM25) findet sie. Hybride Suche führt beides aus und mischt die Werte. Weaviate, Qdrant, Milvus, LanceDB und turbopuffer tun das in einer Engine; Pinecone bietet Sparse-Dense-Indizes oder einen Volltextfilter; bei pgvector kombinierst du die Volltextsuche von Postgres selbst in SQL. Prüfe, ob du die Gewichtung einstellen oder Reciprocal Rank Fusion nutzen kannst.
03
Recall gegenüber Latenz
Approximative Suche tauscht Genauigkeit gegen Geschwindigkeit: Recall ist der Anteil der wahren nächsten Nachbarn, den sie findet, und du willst ihn bei der Antwortzeit, die du brauchst, nicht bei beliebiger Geschwindigkeit. HNSW, ein geschichteter Graph, liefert hohen Recall, will den Index aber im RAM; IVF bildet Cluster aus Vektoren und durchsucht die nächstgelegenen Cluster; festplattenbasierte Indizes (DiskANN bei Milvus, HFresh bei Weaviate, SPFresh oder SPANN bei turbopuffer und Chroma Cloud) halten die meisten Daten auf SSD oder Object Storage. Quantisierung verkleinert Vektoren um das 4- bis 32-Fache, meist mit einem Schritt zur Neubewertung, um Genauigkeit zurückzugewinnen. Zu Benchmarks: ANN-Benchmarks, betrieben von den Wissenschaftlern Martin Aumueller, Erik Bernhardsson und Alec Faitfull, trägt Recall gegen Anfragen pro Sekunde für einzelne Anfragen auf kleinen öffentlichen Datensätzen auf; es vergleicht Indexalgorithmen, nicht Datenbanken, und ignoriert Filterung, Schreibvorgänge und Betrieb. VectorDBBench wird von Zilliz gepflegt, dem Unternehmen hinter Milvus, und ergänzt Latenz bei p99, Fälle mit Filtern und Streaming sowie Kosten pro Anfrage. Vergleiche QPS und p99 beim selben Recall und behandle den Benchmark eines Anbieters zum eigenen Produkt als Behauptung, die zu reproduzieren ist.
04
Kapazität für die Arbeitslast
Bemiss die Aufgabe, bevor du wählst: erwartete Zahl an Vektoren, Dimensionen, gleichzeitige Anfragen und wie oft sich Daten ändern. Vektoren mal Dimensionen mal Bytes ergibt den rohen Speicher, den ein In-Memory-Index braucht. Encore, das Postgres-Hosting verkauft, sieht pgvector unter etwa fünf Millionen Vektoren gleichauf mit Pinecone und darüber auf sorgfältige Optimierung angewiesen; Chroma passt für Prototypen bis zu Dutzenden Millionen; laut FAQ von LanceDB bewältigt die Open-Source-Bibliothek Millionen Vektoren auf einem Knoten; Milvus und turbopuffer sind für Milliarden gebaut.
05
Updates und Löschung
Prüfe, wie schnell Einfügungen, Änderungen und Löschungen durchsuchbar werden. Manche Indizes nehmen neue Daten sofort auf, andere puffern Schreibvorgänge oder brauchen einen Neuaufbau; Schreibvorgänge bei turbopuffer gehen mit 248 ms bei p90 für einen Upsert von 512 KB in den Object Storage. Löschung zählt für die Compliance: Wenn ein Nutzer ein Dokument zurückzieht, muss es zügig aus den Ergebnissen verschwinden, und Indizes pro Mandant machen das Löschen eines ganzen Kunden einfach.
06
Sicherheit und Isolation
Achte auf Zugriffskontrolle, Verschlüsselung im Ruhezustand und bei der Übertragung und eine Mandantentrennung, die hält. Wenn Berechtigungen über einen Metadatenfilter durchgesetzt werden, muss dieser Filter bei jeder Anfrage zuverlässig sein, ein weiterer Grund, den gefilterten Recall zu testen. turbopuffer bietet unbegrenzte Namespaces und vom Kunden verwaltete Schlüssel in Enterprise; Qdrant kann ein Feld als Mandantenschlüssel markieren; Weaviate hat native Mandantenfähigkeit, wobei seine Namespaces-Funktion inzwischen eine kostenpflichtige Lizenz braucht; in pgvector partitionierst du nach Mandant oder nutzt Row-Level Security.
07
Betrieb
Backups, Wiederherstellung, Monitoring und Skalierung kosten oft mehr als die Lizenz. pgvector bringt nichts Neues zu betreiben, wenn du schon Postgres hast. Qdrant kommt als einzelne Binary; Milvus braucht im großen Maßstab Kubernetes und ein Plattformteam. Chroma und LanceDB laufen in deinem Prozess. Pinecone und turbopuffer gibt es nur verwaltet, mit Bring-your-own-Cloud für Enterprise-Kunden. Die Lizenz entscheidet über deinen Ausstieg: Apache 2.0 (Qdrant, Milvus, Chroma, LanceDB) und die PostgreSQL-Lizenz (pgvector) erlauben freies Selbsthosten, Weaviate ist seit September 2026 Open Core, und bei den proprietären Diensten heißt Ausstieg exportieren und neu indexieren.
08
Gesamtkosten
Zähle Indizes, Speicher für Metadaten, Anfragen und Updates und prüfe, ob du überhaupt eine separate Datenbank brauchst. Verwaltete Dienste rechnen in verschiedenen Einheiten ab: Pinecone nach Read Units, Write Units und gespeicherten GB, Weaviate Cloud nach gespeicherten Vektordimensionen, turbopuffer nach Nutzung über einem monatlichen Minimum, Chroma Cloud nach geschriebenen, gespeicherten und abgefragten Daten. Ein lesestarker Chatbot und eine schreibstarke Indexierungspipeline können dieselben Anbieter in umgekehrter Reihenfolge einstufen, rechne also deine eigenen Volumen mit jedem Rechner durch und vergleiche mit einer Instanz, die du selbst betreiben würdest.
Welcher Ansatz für welche Daten
Unterschiedliche Inhalte brauchen unterschiedliche Modelle. Viele Systeme nutzen mehrere und routen nach Datentyp.
| Deine Daten | Ansatz | Starte mit |
|---|---|---|
| Schon auf Postgres, unter etwa 10 Millionen Vektoren | Füge Vektoren der Datenbank hinzu, die du betreibst; Filter sind SQL, und es gibt nichts Neues zu betreiben. | pgvector |
| Mandantenfähiges SaaS mit Berechtigungen pro Nutzer | Wähle starke gefilterte Suche oder einen Namespace pro Mandant und teste Berechtigungsfilter auf Recall. | Qdrant, turbopuffer, Weaviate |
| Starker Bedarf an Stichwörtern: Namen, Codes, Kennungen | Nimm eine Engine mit eingebauter hybrider Suche aus BM25 und Vektoren. | Weaviate, Qdrant, Milvus |
| Hunderte Millionen bis Milliarden Vektoren | Nutze eine verteilte Engine oder eine auf Object-Storage-Basis, die für diese Größenordnung gebaut ist. | Milvus, turbopuffer |
| Kein Betriebsteam, unvorhersehbarer Traffic | Nutze einen vollständig verwalteten Dienst und begrenze die Ausgaben mit Tariflimits. | Pinecone, turbopuffer |
| Auf dem Gerät, in Notebooks oder für lokale Agenten | Betreibe eine eingebettete Bibliothek im Prozess, ohne Server. | Chroma, LanceDB |
| Multimodale Daten in einem Data Lake | Halte Embeddings neben den Rohdateien und durchsuche sie an Ort und Stelle. | LanceDB, Milvus |
So testest du es mit deinen eigenen Daten
- Stell 50 bis 100 repräsentative Fragen zusammen und markiere für jede die richtigen Abschnitte.
- Nimm schwierige Fälle auf: Abkürzungen, exakte IDs und Codes, mehrdeutige Fragen und Dokumente mit eingeschränkten Berechtigungen.
- Miss Recall@k: wie oft die richtigen Abschnitte unter den ersten k Ergebnissen erscheinen.
- Miss die Qualität der Rangfolge, etwa NDCG@10 oder MRR, damit der richtige Abschnitt weit oben steht und nicht nur vorhanden ist.
- Miss die Latenz bei p95 unter realistischer Gleichzeitigkeit mit eingeschalteten echten Filtern.
- Rechne die Gesamtkosten dazu: Indexierung, Speicher, Anfragen und Updates bei deinem erwarteten Volumen.
- Prüfe die Qualität der finalen Antworten und bewerte die ganze Pipeline (Embedding-Modell, Datenbank, Reranker und LLM) zusammen, nicht nur die Datenbank.
Wie sich die Optionen unterscheiden
Zwei Entscheidungen werden leicht verwechselt. Das Embedding-Modell entscheidet, was als ähnlich gilt; die Vektordatenbank entscheidet, wie effizient du diese Embeddings speicherst, filterst und abrufst. Bewerte sie getrennt und teste sie dann zusammen mit deinen eigenen Daten. Und bevor du ein neues System hinzufügst, prüfe die Datenbank, die du schon betreibst: Wenn ihre Vektorsuche deine Anforderungen an Retrieval und Filterung erfüllt, brauchst du vielleicht keine weitere.
Vektordatenbanken fallen in fünf Familien. Eine Postgres-Erweiterung (pgvector) legt Embeddings in eine gewöhnliche Tabelle, Filter sind also SQL, Daten bleiben in denselben Transaktionen und Backups, und es gibt nichts Neues zu betreiben; sie ist der Standard für einige Millionen Vektoren. Eigene Engines (Qdrant, Weaviate, Milvus) sind separate Server, die nur für die Suche gebaut sind: Sie bewältigen starke Filterung, hybride Suche aus Stichwort und Vektor, Quantisierung und größere Skalierung, zum Preis eines weiteren Systems im Betrieb. Qdrant ist am einfachsten zu betreiben, Weaviate führt bei hybrider Suche und eingebautem Embedding, und Milvus ist darauf ausgelegt, Milliarden Vektoren über viele Maschinen zu verteilen.
Eingebettete Bibliotheken (Chroma, LanceDB) laufen wie SQLite in deiner Anwendung, ohne Server: ideal für Prototypen, Notebooks, lokale Apps und Agenten, schwächer bei vielen gleichzeitigen Nutzern. Vollständig verwaltete Dienste (Pinecone, turbopuffer) nehmen dir den Betrieb ganz ab und rechnen nach Nutzung ab; Pinecone hält Indizes heiß, während turbopuffer Daten im Object Storage hält, was im riesigen Maßstab günstiger, bei kalten Anfragen aber langsamer ist. Suchmaschinen mit Vektorunterstützung (Elasticsearch, OpenSearch) und Graphdatenbanken wie Neo4j speichern ebenfalls Vektoren, was sinnvoll ist, wenn du sie schon für Stichwortsuche oder Beziehungen betreibst, sie werden hier aber nicht behandelt.
8 Tools im Vergleich
Sortiert nach unserer Bewertung. Öffne einen Testbericht für Quellen, Preise und das vollständige Fazit.
| Tool | Bewertung | Unser Fazit | Ideal für | Preis |
|---|---|---|---|---|
| QdrantRepo | 4.7/5 | Gefilterte Vektorsuche, die richtig gemacht ist, macht Qdrant zur Open-Source-Datenbank, an der sich produktive RAG-Systeme messen lassen müssen, solange jemand einen Server absichert, der offen ausgeliefert wird. | Teams mit produktivem RAG oder produktiver Suche, die schnelle gefilterte Vektorabfragen brauchen. | Kostenlos und Open Source unter der Apache-2.0-Lizenz. Qdrant Cloud bietet einen kostenlosen Cluster mit 1 GB, danach nutzungsbasierte Abrechnung; Premium, Hybrid und Private Cloud werden über den Vertrieb bepreist. |
| pgvectorRepo | 4.6/5 | Für die meisten Teams, die schon auf Postgres sind, ist eine eigene Vektordatenbank zusätzliche Infrastruktur, die pgvector überflüssig macht. | Teams, die schon auf Postgres sind und RAG oder semantische Suche über einige Millionen Vektoren bauen. | Kostenlos und Open Source unter der PostgreSQL License. Die einzigen Kosten sind die Postgres-Instanz, die du schon betreibst, oder eine größere. |
| MilvusRepo | 4.4/5 | Gebaut für Milliarden von Vektoren und bezahlt mit Betriebsaufwand; unterhalb einiger hundert Millionen ist es mehr Datenbank, als die meisten Teams brauchen. | Plattformteams, die Vektorsuche mit Hunderten Millionen bis Milliarden Vektoren betreiben. | Kostenlos und Open Source unter Apache 2.0. Zilliz Cloud ist der verwaltete Dienst: kostenlose Stufe (5 GB, fünf Collections), Dedicated ab 63 $, 16 $ oder 5 $ pro Million Vektoren mit 768 Dimensionen im Monat (performance, capacity oder tiered), Enterprise ab 197 $ im Monat, Business Critical auf Angebot. |
| PineconeTool | 4.2/5 | Pinecone nimmt der Vektorsuche fast die gesamte Betriebsarbeit ab und lässt sich das bei jedem Lesevorgang bezahlen, was einem kleinen Team weit besser passt als einem stark genutzten Produktionsindex. | Teams ohne eigenes Personal für den Datenbankbetrieb, die verwaltete Vektorsuche wollen und nutzungsbasierte Gebühren akzeptieren. | Starter kostenlos (2 GB, 1 Mio. Read Units/Monat, nur AWS us-east-1). Builder pauschal 20 $/Monat mit festen Kontingenten. Standard mindestens 50 $/Monat, dann 0,33 $/GB/Monat für Speicher, 16 bis 18 $ pro 1 Mio. Read Units, 4 bis 4,50 $ pro 1 Mio. Write Units. Enterprise mindestens 500 $/Monat. |
| WeaviateRepo | 4.2/5 | Die hybride Suche aus Schlüsselwörtern und Vektoren ist weiterhin Weaviates bestes Argument, aber die neuesten Betriebsfunktionen liegen inzwischen hinter einem Lizenzschlüssel. | Teams, die Suche oder RAG bauen, bei denen exakte Schlüsselwörter und semantische Ähnlichkeit gleichermaßen zählen. | Der Kern steht unter BSD-3-Clause; einige Enterprise-Funktionen brauchen einen bezahlten Lizenzschlüssel. Weaviate Cloud: Free (100.000 Objekte), Flex nach Verbrauch mit einem Minimum von 45 $ pro Monat, Premium ab 400 $ pro Monat mit Vorauszahlungsvertrag. |
| turbopufferTool | 4.2/5 | turbopuffer ist die Vektordatenbank, an der sich andere messen müssen, wenn dein Produkt Millionen getrennter, meist ungenutzter Indizes hat, solange du damit leben kannst, dass die erste Suche in einem kalten Index etwa eine Sekunde dauert. | Teams, die mandantenfähige KI-Produkte mit vielen getrennten Indizes oder Milliarden Vektoren bauen und keine Server betreiben wollen. | Launch 16 $/Monat Mindestnutzung; Scale 256 $/Monat Minimum (SSO, HIPAA BAA); Enterprise ab 4.096 $/Monat mit 35 % Aufschlag auf die Nutzung (BYOC, Single-Tenant, SLA von 99,95 %). Speicher bis 0,33 $/GB, Schreibvorgänge bis 2 $/GB, Abfragen bis 1 $/PB durchsucht. Keine Gratis-Stufe. |
| ChromaRepo | 4.1/5 | Schnell eingebettet und günstig gehostet für leselastiges RAG, allerdings wurde seit Mai 2026 nichts mehr getaggt. | Entwickler, die RAG-Prototypen bauen oder kleine bis mittelgroße Vektorsuchen betreiben. | Kostenlos und Open Source unter Apache 2.0. Chroma Cloud: Starter 0 $ plus Nutzung mit 5 $ Guthaben; Team 250 $/Monat plus Nutzung; Enterprise individuell. Schreiben 2,50 $/GiB, Speicher 0,33 $/GiB-Monat. |
| LanceDBRepo | 4.0/5 | Wenn deine Embeddings neben Bildern, Videos oder Trainingsdaten liegen, macht LanceDB die separate Datenbank ganz überflüssig, auch wenn stark frequentierte Suche mit vielen Nutzern nicht das ist, wofür die kostenlose Bibliothek gebaut ist. | Teams, die mit multimodalen Daten oder Trainingsdaten arbeiten und Vektorsuche ohne eigenen Server wollen. | Kostenlos und Open Source unter Apache 2.0. LanceDB Enterprise wird über Jahresverpflichtungen verkauft; AWS Marketplace listet eine 12-monatige Verpflichtung über 60.000 $, private Angebote auf Anfrage. |
Im direkten Vergleich
Die Spezifikationen, die für diesen Schritt zählen. Geprüft am 23. Okt. 2026; prüf sie auf der Website des Anbieters, bevor du dich festlegst.
| Tool | Typ | Lizenz | Indextypen | Hybride Suche | Hosting-Optionen | Ideale Größenordnung |
|---|---|---|---|---|---|---|
| Qdrant | Eigene Engine (Rust) | Apache 2.0 | HNSW, sparse invertiert; TurboQuant/BQ/PQ | Ja, sparse + dense in einer Anfrage | Selbst hosten, Qdrant Cloud, Edge | Millionen bis Hunderte Millionen |
| pgvector | Postgres-Erweiterung | PostgreSQL-Lizenz | HNSW, IVFFlat; half, binary, sparse | Über die Volltextsuche von Postgres in SQL | Jedes Postgres, die meisten verwalteten Dienste | Einige Millionen Vektoren (laut Encore etwa 5M) |
| Milvus | Verteilte Engine (Go/C++) | Apache 2.0 | HNSW, IVF, DiskANN, SCANN, flach | Ja, BM25 + sparse + dense | Selbst hosten (Kubernetes), Zilliz Cloud | Hunderte Millionen bis Milliarden |
| Pinecone | Vollständig verwalteter Dienst | Proprietär | Nicht veröffentlicht | Sparse-Dense oder Volltextfilter | Serverless; BYOC in Enterprise | Beliebig; Kosten wachsen mit Lesezugriffen |
| Weaviate | Eigene Engine (Go) | BSD-3-Kern + kommerzielle Funktionen | HNSW, flach, dynamisch, HFresh | Ja, BM25 + Vektor, einstellbar | Selbst hosten, Weaviate Cloud | Nicht veröffentlicht |
| turbopuffer | Verwaltet, auf Basis von Object Storage | Proprietär | SPFresh + binäre Quantisierung mit RaBitQ | Ja, BM25 + Vektor | Multi-Tenant, Single-Tenant, BYOC | Milliarden Vektoren, viele Mandanten |
| Chroma | Eingebettete Bibliothek oder Server | Apache 2.0 | HNSW (ein Knoten), SPANN (Cloud) | Volltext neben Vektoren | Im Prozess, Server, Chroma Cloud | Prototypen bis Dutzende Millionen |
| LanceDB | Eingebettete Bibliothek (Lance-Dateien) | Apache 2.0 | IVF (PQ/SQ/RQ), IVF_HNSW | BM25-Volltext + Vektor | Im Prozess auf Festplatte oder S3; Enterprise | Lokale Apps; Millionen Vektoren pro Knoten |
Verbinde es mit deinem Agenten
MCP-Server, mit denen Assistenten wie Claude, ChatGPT und Cursor diese Tools direkt nutzen können.
Wo diese Stufe hingehört
- Mit deinen Dokumenten chatten: Wir würden mit Qdrant anfangen.
- Kundensupport-Agent: Wir würden mit pgvector anfangen.
- Coding-Agent: Wir würden mit LanceDB anfangen.
- Recherche und Knowledge Graph: Wir würden mit Weaviate anfangen.
- Assistent mit Langzeitgedächtnis: Wir würden mit Qdrant anfangen.
- Pipeline für Bildgenerierung: Wir würden mit Qdrant anfangen.
- Videoproduktion: Wir würden mit LanceDB anfangen.
- Sprachagent: Wir würden mit pgvector anfangen.
- Private KI auf dem eigenen Gerät: Wir würden mit LanceDB, Chroma anfangen.
Quellen für diesen Leitfaden
- ANN-Benchmarks
- VectorDBBench (Zilliz) on GitHub
- VectorDBBench leaderboard
- Qdrant docs: indexing
- Qdrant docs: quantization
- Weaviate docs: vector indexes
- Milvus docs: index types
- Milvus docs: DiskANN
- Chroma docs: collection configuration
- Chroma docs: architecture
- LanceDB docs: indexing
- Pinecone docs: hybrid search
- pgvector README
- turbopuffer: ANN v3
- LanceDB OSS FAQ
- pgvector vs Pinecone (Encore)