Kapitel 4 — Die richtige Vektordatenbank wählen
Vierter Beitrag der kapitelweisen Tour durch LLM Primer III: Enhancing Enterprise AI with RAG. Der Teil eines RAG-Systems, der am schnellsten wächst, im Maßstab am meisten kostet und das Team am stärksten festlegt — technisch gewählt, operativ entschieden.
Warum dieses Kapitel existiert
Die Vektordatenbank ist die Speicherschicht des Retrieval-Systems, und die Wahl ist eine mehrachsige Entscheidung — Performance, Datenresidenz, die operative Form des Teams, die Gesamtkosten über die Systemlebenszeit. Eine falsche Wahl legt das Team über Jahre fest, denn eine Milliarde Embeddings zwischen Systemen umzuziehen ist ein Projekt, das niemand auf die leichte Schulter nimmt. Technische Vergleiche sind nützlich, aber entschieden wird meistens auf den drei Achsen, die sie umgehen: wo die Daten leben dürfen, was das Team betreiben kann und was das System über seine Lebenszeit kostet.
4.1 Architekturen: purpose-built versus Erweiterungen
Die erste, oft unausgesprochene Entscheidung ist die zwischen einem neuen, eigens für Vektor-Workloads gebauten System und der Erweiterung eines Systems, das das Team ohnehin betreibt. Eine purpose-built Datenbank — Pinecone, Qdrant, Milvus, Weaviate, Vespa — ist vom Index aus nach außen entworfen. Query-Planer, Speicherlayout, Replikationsmodell und API sind alle für approximative Nearest-Neighbor-Abfragen auf hochdimensionalen Vektoren ausgelegt. Höhere Leistungs-Decken, besonders bei hybriden Filter-plus-Vektor-Abfragen; ein weiteres System im Betrieb.
Ein Erweiterungs-Ansatz — pgvector, Elasticsearch dense_vector, MongoDB Atlas Vector Search, Redis mit RediSearch — fügt Vektorsuche zu einer Datenbank hinzu, die das Team bereits fährt. Keine neue Authentifizierung, Backup-Prozedur, On-Call-Rotation oder Patch-Kadenz. Die Leistungs-Decke wird von der Architektur des Hosts gesetzt und liegt meist deutlich über dem, was Anwendungen unterhalb des Bereichs von zehn Millionen Vektoren brauchen. Die Entscheidung ist selten eine reine Performance-Frage. Sie ist meist eine Frage, wo das Team sein operatives Budget ausgeben will — ein Team, das eine Postgres-Datenbank betreibt, will keine zweite betreiben; ein Team mit zehn Datendiensten zuckt bei einem elften nicht.
4.2 Managed-Leader: Pinecone und Vertex
Pinecone ist die kanonische Managed-Vektordatenbank. Operative Einfachheit, vorhersagbare Latenz, ein gereiftes SDK und eine Serverless-Stufe, die Speicher von Rechenleistung trennt und nach tatsächlicher Nutzung statt nach reservierter Kapazität bepreist. Die richtige Voreinstellung für neue Deployments, sofern der Workload nicht spezifisch von reservierter Kapazität profitiert. Der Preis ist die architektonische Bindung, die jedes proprietäre Managed-System mit sich bringt — Embeddings sind im Prinzip portierbar, aber die Export-und-Reindex-Kosten sind real. Vertex AI Vector Search ist Googles Angebot, gebaut auf der ScaNN-Bibliothek, die Googles eigene große Ähnlichkeitssuche speist. Höhere Skalierungs-Decke, enge Integration mit dem Rest von GCP — Embedding-Modelle, IAM, Cloud Monitoring — und das entsprechende strategische Bekenntnis zu einer Cloud. Azure AI Search nimmt dieselbe Position für Teams ein, die sich auf Microsoft festgelegt haben. Die Wahl unter den drei Plattform-nativen Optionen folgt meist dem bestehenden Cloud-Bekenntnis, was vernünftig ist, solange das Team Skalierung und Residenz geprüft hat.
4.3 Open Source: Qdrant, Milvus, Weaviate
Die Open-Source-Kategorie ist für Teams, die ihre Infrastruktur selbst kontrollieren wollen — aus Kosten-, Residenz- oder strategischen Gründen — und die operative Kapazität haben, verteilte Systeme zu betreiben. Qdrant ist das kleinste und fokussierteste: in Rust geschrieben, als Single-Binary deploybar, für niedrige Latenz bei Vektorsuche mit starkem Filtering und Quantisierung ausgelegt. Zugänglich genug, um in Minuten zu laufen; die richtige Wahl für den kleinstmöglichen operativen Fußabdruck. Milvus ist das größte und enterprise-orientierteste — cloud-native Architektur, die Compute, Storage und Metadaten trennt, mit der höchsten Skalierungs-Decke der Kategorie (Milliarden-Korpora, GPU-beschleunigte Indizes, getierter Speicher). Erhebliche operative Komplexität, gemildert durch Zilliz Cloud. Weaviate sitzt dazwischen — feature-reicher als Qdrant, weniger komplex als Milvus, mit eingebauten Modulen für Embedding, Reranking und Mehrmandantenfähigkeit. Eher eine Such-Plattform als ein reiner Such-Index. Alle drei sind im Kern Apache-lizenziert mit bezahlten Managed-Angeboten, und Benchmarks liegen innerhalb eines kleinen konstanten Faktors. Die Entscheidung ist Passung, nicht rohe Performance.
4.4 Embedded und Postgres: Chroma und pgvector
Die meisten realen RAG-Deployments bedienen Dutzende Queries pro Sekunde über ein paar hunderttausend Vektoren, nicht Millionen pro Sekunde über Milliarden. Für diese Workloads läuft das richtige Werkzeug im Anwendungsprozess oder daneben. Chroma ist die eingebettete Option — standardmäßig in-process, persistiert auf lokale Platte, der einfachste Fall braucht keine Konfiguration. Richtig für Prototypen, Werkzeuge, die mit ihren eigenen Daten ausgeliefert werden, und Produktions-Deployments, die auf eine Maschine passen. pgvector fügt einen Vektor-Typ, Distanz-Operatoren und HNSW/IVFFlat-Indizierung zu Postgres hinzu. Für Korpora bis grob zehn Millionen Vektoren auf einem gut bestückten Host ist pgvector eine glaubwürdige Produktionswahl und die operativ einfachste Option für Teams, die schon Postgres betreiben. Vektorsuche wird zur SQL-Abfrage gegen eine Tabelle, die der bestehende ORM versteht; Joins mit strukturierten Metadaten sind erstklassig. Die versteckte Tugend dieser Optionen ist, dass sie die Kosten senken, die Meinung zu ändern — die Migration auf ein verteiltes System bleibt, falls sie kommt, begrenzt.
4.5 Residenz, Betrieb und Kosten — die Achsen, die wirklich entscheiden
Die drei operativen Achsen verdienen Namen, weil dort Produktionsentscheidungen wirklich fallen. Datenresidenz verkürzt die Kandidatenliste, bevor irgendein technischer Vergleich Sinn ergibt. EU-Datenschutz, Finanzdienstleisterregulierung, sovereign-cloud-Bekenntnisse — diese Restriktionen sind nicht verhandelbar, und die erste Frage an jeden Anbieter ist, welche Regionen er unterstützt und welche vertraglichen Datenhandhabungs-Verpflichtungen er eingeht. Ein besonderer Stolperstein: Embeddings sind abgeleitete Daten, bleiben aber unter den meisten regulatorischen Rahmen personenbezogene Daten, weil sie invertiert oder per Ähnlichkeit zum Original zurückverfolgt werden können. Ein Vertrag, der Rohdokumente abdeckt, aber bei Embeddings vage bleibt, ist unvollständig.
Die operative Form ist die Kapazität des Teams selbst. Ein Drei-Personen-Team mit einem Anwendungsdienst sollte die Option wählen, die die geringste operative Oberfläche addiert — pgvector, ein Managed Pinecone oder Qdrant Cloud, eingebettetes Chroma. Ein Team von dreißig kann die Komplexität eines verteilten Open-Source-Systems für seine Kosten- und Fähigkeitsvorteile aufnehmen. Der Fehler ist, ein System zu wählen, das nicht zur tatsächlichen Betriebs-Kapazität des Teams passt. Die Gesamtkosten über die Systemlebenszeit umfassen Bereitstellung, Monitoring, Backup, Restore-Übungen, Kapazitätsplanung, Upgrade-Arbeit und den anteiligen On-Call-Aufwand. Die ehrliche Rahmung fragt die Kosten in drei Szenarien — aktueller Workload, 10x, 100x — denn die Steigung der Kurve zählt so viel wie der Ausgangspunkt.
Was Kapitel 4 vorbereitet
Die Vektordatenbank bestimmt, was die Speicherschicht halten kann, wie schnell sie abgefragt werden kann, welche Filter- und Metadatenmuster sie unterstützt. Keine dieser Eigenschaften allein entscheidet die Retrieval-Qualität — sie entscheiden, was darauf gebaut werden kann. Was darauf gebaut wird, ist die Retrieval-Pipeline, in der sich die Gewinne aufsummieren: hybride Suche, die Dense-Vektoren mit BM25 kombiniert, Reciprocal Rank Fusion über heterogene Retriever, Cross-Encoder-Reranking und die Query-Understanding-Schicht, die Nutzerfragen mit Dokumentantworten verbindet.
Als Nächstes — Kapitel 5: Die Retrieval-Pipeline architektonisch denken. Wie Dense-Vektorsuche und Keyword-Retrieval per Reciprocal Rank Fusion kombiniert werden, der Cross-Encoder-Reranking-Schritt, der den meisten verbleibenden Qualitätsspalt schließt, und die Query-Understanding-Schicht, die den Rest erledigt.
