Eine der ersten Entscheidungen bei einem RAG-Projekt ist die Vector-DB. Der Markt hat sich seit 2023 explosionsartig vergrößert und die Landschaft ist unübersichtlich geworden. Für DACH-Mittelstand-Projekte reduzieren wir das inzwischen auf drei Kandidaten: pgvector, Qdrant und Weaviate. Was passt für wen, und welche Fehler sehen wir am häufigsten.
Warum wir Pinecone, Milvus und Chroma nicht empfehlen
Vorweg drei Vector-DBs, die wir aktuell für DACH-B2B-Setups nicht mehr in die engere Wahl nehmen.
Pinecone ist Managed-Only und US-basiert. Für DSGVO-sensible Daten wird EU-Region angeboten, aber das Setup ist zusätzlich zu buchen und die Data-Processing-Agreement-Situation seit dem Schrems-II-Urteil weiterhin kompliziert. Wir kennen erfolgreiche Setups, aber der Aufwand für Compliance-Dokumentation ist überproportional. Für Startups mit US-Fokus fein, für DACH-Mittelstand meist nicht die richtige Wahl.
Milvus ist technisch solide, aber das Ökosystem und die Dokumentation sind wesentlich schwerer als bei Qdrant. Bei den Teams, die wir sehen, gibt es niemanden mit tiefer Milvus-Erfahrung. Wenn die einzige Person mit Milvus-Wissen kündigt, wird der Betrieb schnell fragil.
Chroma ist super für Notebooks und POCs. Für Production im Mittelstand fehlt aktuell die Reife bei Backup, Multi-Tenant-Isolation und rollierender Migration. In sechs Monaten könnte das anders aussehen.
pgvector: der pragmatische Standard
pgvector ist eine PostgreSQL-Extension, die Vector-Search direkt in eurer bestehenden Datenbank ermöglicht. Für die meisten DACH-Mittelstand-Setups die richtige erste Wahl.
Was funktioniert gut:
- Ihr habt sowieso PostgreSQL im Einsatz. Zero neue Infrastruktur, kein neuer Vendor, kein neues Backup-Konzept.
- HNSW-Index seit Version 0.5.0 macht Retrieval bis zu 10 Millionen Vektoren praktikabel.
- Volle SQL-Power: Filter, Joins, Aggregations, RLS. Ein Query kann Vector-Similarity, User-Berechtigung und Zeit-Filter kombinieren.
- Backup, Replikation, Migrations funktionieren wie bei jeder PostgreSQL-Anwendung. Der DB-Admin muss keinen neuen Stack lernen.
Wo es weh tut:
- Für Datensätze über 10 Millionen Vektoren wird die Latenz merklich schlechter. Ab 50 Millionen ist es tatsächlich problematisch.
- Multi-Tenant-Isolation über Schemas oder Row-Level-Security funktioniert, ist aber komplexer als bei dedizierten Vector-DBs.
- Kein eingebautes Reranking, kein hybrid Sparse+Dense out-of-the-box.
Wann pgvector: Ihr habt unter 5 Millionen Vektoren pro Tenant, PostgreSQL bereits im Stack, ein DB-Admin-Team, und braucht keine spezialisierten Vector-Features wie Reranking.
Qdrant: die Managed-Alternative mit EU-Region
Qdrant ist eine dedizierte Vector-DB in Rust geschrieben. Wir haben mehrere Production-Setups auf Qdrant Cloud und self-hosted Qdrant und sind mit beiden zufrieden.
Was funktioniert gut:
- Qdrant Cloud bietet EU-Region-Deployment mit klarem DPA. DSGVO-Konfiguration ist geradlinig.
- Filterbare Metadaten sind ein First-Class-Feature. Filter auf Kategorien, Berechtigungen, Zeitstempel läuft schnell.
- Payload-Storage direkt neben dem Vector ermöglicht kombinierte Filter- und Similarity-Queries ohne separate DB-Abfrage.
- Hybrid-Search (Sparse + Dense) wird nativ unterstützt.
- Snapshots und Backup-Mechanismen sind produktionsreif.
Wo es weh tut:
- Für Multi-Tenant-Setups muss man mit Collections arbeiten und eigene Access-Layer bauen. Für harte Isolation eher schwierig.
- Der Betrieb der self-hosted Version ist deutlich anspruchsvoller als PostgreSQL — es ist ein neuer Stack, den euer Team lernen muss.
Wann Qdrant: Ihr habt zwischen 5 und 200 Millionen Vektoren, braucht Hybrid-Search oder komplexe Metadaten-Filter, und habt Kapazität für einen dedizierten Stack.
Weaviate: die Feature-reiche Option
Weaviate ist eine graph-basierte Vector-DB mit vielen eingebauten Features. Wir setzen sie seltener ein, aber für die richtigen Use-Cases sehr passend.
Was funktioniert gut:
- Eingebautes Modul-System für Reranking, Cross-Encoders und LLM-Integration direkt in der DB. Wenn ihr eine mehrstufige Pipeline aus Retrieve → Rerank → Generate wollt, ist vieles bereits vorbereitet.
- GraphQL-API neben REST — für Frontend-Teams oft angenehmer.
- Multi-Tenant-Isolation als First-Class-Feature. Jeder Tenant kann eine separate Collection sein, mit eigenen Konfigurationen.
Wo es weh tut:
- Der Komplexitäts-Overhead im Betrieb ist real. Weaviate hat viele Konfigurationsmöglichkeiten, was Setup-Aufwand bedeutet.
- Die eingebauten LLM-Module machen Vendor-Lock-in wahrscheinlicher als bei pgvector oder Qdrant.
- Managed-Service ist etwas teurer als Qdrant Cloud.
Wann Weaviate: Multi-Tenant von Anfang an geplant, komplexe Pipelines mit Reranking, Team mit Kapazität für einen anspruchsvolleren Stack.
Die häufigsten Auswahl-Fehler
Wir sehen drei Muster wiederkehrend.
Fehler 1: "Wir nehmen was cool klingt". Team liest Blog-Post über Pinecone, bucht Pinecone. Sechs Monate später steht das Team vor der DSGVO-Frage und muss migrieren. Der Migrations-Aufwand ist mindestens ein Sprint.
Fehler 2: "Wir nehmen das schnellste". Benchmarks-Vergleich zeigt: Weaviate 15% schneller als Qdrant. Team wählt Weaviate. Sechs Monate später kann niemand im Team Weaviate-Konfiguration beurteilen, und der 15%-Vorteil ist im Alltag irrelevant, weil Latenz eh unter 200ms liegt.
Fehler 3: "Wir nehmen mehrere". Team entscheidet, pgvector für die eine Kategorie und Qdrant für die andere. Doppelter Operations-Overhead, doppelte Migration bei Model-Wechsel, keine einheitliche Beobachtung. Für den DACH-Mittelstand fast nie sinnvoll.
Entscheidungs-Kurzschema
Basierend auf ~15 RAG-Projekten der letzten 24 Monate.
- Unter 5 Millionen Vektoren, PostgreSQL im Stack, DACH-Team: pgvector.
- 5-100 Millionen Vektoren, brauchen Hybrid-Search oder EU-Managed: Qdrant Cloud in Frankfurt.
- 100+ Millionen Vektoren, komplexe Pipelines, Multi-Tenant von Sprint 1: Weaviate.
- Alles bis "was cool klingt": siehe Fehler 1.
Wenn ihr unsicher seid, schaut euch den Reifegrad-Check an. Frage 2 mappt direkt auf die Vector-DB-Wahl und gibt euch eine erste Orientierung.