Pexon Consulting | 10 Min. Lesezeit | 04.08.2026
TL;DR
Für Enterprise-RAG entscheidet nicht die schnellste Vektorsuche, sondern Filter-Recall, Betrieb und Souveränität. pgvector passt, wenn Sie schon Postgres fahren, Qdrant bei hoher Skalierung und harten Filtern, Azure AI Search bei Managed-Betrieb mit eingebautem Reranking. Pexon (80 Mitarbeiter, Deutschland, Microsoft-Partner) baut die passende RAG-Retrieval-Schicht als 6-Wochen-Pilot.
Das Problem: RAG scheitert am Retrieval, nicht an der Datenbank
Die Vektordatenbank ist selten der Grund, warum ein RAG-System schlechte Antworten gibt. Der Grund ist fast immer schlechtes Retrieval: Die relevanten Chunks landen nicht in den Top-K, weil Filter die Trefferliste zerschießen oder reine Vektorsuche ohne Keyword-Anteil danebengreift. Wer drei Vektordatenbanken nur nach roher Suchgeschwindigkeit vergleicht, misst die falsche Größe.
Für Enterprise-RAG zählen vier Dinge in dieser Reihenfolge: Wie gut findet die DB relevante Chunks, wenn gleichzeitig nach Metadaten gefiltert wird (Mandant, Berechtigung, Datum)? Wie hoch ist der Betriebsaufwand? Wo laufen die Daten, im eigenen Netz oder in der Cloud? Und erst dann: Latenz und Kosten. Azure AI Search, Qdrant und pgvector beantworten diese vier Fragen unterschiedlich, und genau daran entscheidet sich die Wahl.
Unsere klare Position: Die Datenbank ist eine Konsequenz aus Ihrer Architektur, keine Vorentscheidung. Wenn Sie ohnehin eine Enterprise-RAG-Plattform mit Hybrid-Retrieval und Reranking bauen, ist die Vektor-Schicht austauschbar, solange sie gefilterten Recall liefert.
pgvector: die Datenbank, die Sie schon haben
pgvector ist die pragmatische Antwort, wenn PostgreSQL bereits in Ihrem Stack läuft. Version 0.8.2 (Stand 26. Februar 2026) speichert Vektoren bis 16.000 Dimensionen, indexiert per HNSW oder IVFFlat und filtert über normale SQL-WHERE-Klauseln. Kein zweites System, kein zweiter Betrieb, ein Backup-Konzept. Für viele Mittelstands-RAGs ist das der schnellste Weg zu einer produktiven Lösung.
Der entscheidende Fortschritt in 0.8: iterative Index-Scans. Sie lösen das alte Überfilterungs-Problem, bei dem eine kombinierte Vektor- plus WHERE-Suche zu wenige Treffer zurückgab, weil der HNSW-Index vor dem Filter abbrach. pgvector scannt jetzt weiter, bis genug gefilterte Treffer zusammenkommen. Für RAG mit Mandanten- oder Berechtigungsfiltern ist das der Unterschied zwischen brauchbar und unbrauchbar.
-- Hybrid-freundlich: Vektor-Distanz mit Metadaten-Filter in einem Query
SELECT id, inhalt, embedding <=> $1 AS distanz
FROM dokumente
WHERE mandant_id = $2 AND gueltig_ab <= now()
ORDER BY embedding <=> $1
LIMIT 10;Wo pgvector an Grenzen kommt: bei sehr hohen Vektor-Zahlen (grob jenseits einiger Millionen mit hoher QPS) und bei fortgeschrittener Quantisierung. Und ein Betriebshinweis, der zu oft untergeht: pgvector 0.8.2 hat einen Buffer-Overflow bei parallelen HNSW-Builds gefixt (CVE-2026-3172, Datenleck-Risiko). Wer 0.8.0 oder 0.8.1 pinned, gehört auf 0.8.2 aktualisiert. Wie man die Retrieval-Schicht darüber sauber aufbaut, zeigt unsere Anleitung zum RAG-System für die Unternehmens-Wissenssuche.
Qdrant: gebaut für Filter und Skala
Qdrant ist die spezialisierte Vektordatenbank für den Fall, dass pgvector zu klein wird und Sie die Kontrolle behalten wollen. In Rust geschrieben, Apache-2.0-Lizenz, über 27.000 GitHub-Sterne (Stand Ende 2025), als Open-Source, Cloud oder Managed-On-Prem verfügbar. Für Enterprise-RAG interessant ist weniger die rohe Geschwindigkeit als das, was Qdrant beim Filtern tut.
Zwei jüngere Entwicklungen sind hier relevant. Der ACORN-Algorithmus (seit v1.16) traversiert im HNSW-Graph die Nachbarn der Nachbarn, wenn ein Filter die direkten Nachbarn wegschneidet. Das entschärft das klassische „Filter killt meinen Recall“-Problem auf Engine-Ebene, nicht per Workaround. Und die Binary-Quantisierung (seit v1.15) drückt den Speicher bei 1,5 Bit um bis zu Faktor 24, was On-Prem-GPU-Setups spürbar billiger macht. Version 1.17.1 (26. März 2026) ergänzt Relevance-Feedback, um die Trefferqualität ohne Neu-Training der Embeddings nachzujustieren.
from qdrant_client import QdrantClient, models
client = QdrantClient(url="http://localhost:6333")
treffer = client.query_points(
collection_name="dokumente",
query=embedding,
query_filter=models.Filter(must=[
models.FieldCondition(key="mandant_id", match=models.MatchValue(value=42)),
]),
limit=10,
)Unsere klare Empfehlung: Qdrant ist die richtige Wahl, wenn Sie hohe Skalierung, harte Metadaten-Filter und Self-Hosting brauchen, etwa in souveränen Setups für Banking oder Versicherung. Der Preis ist ein eigenes System mit eigenem Betrieb. Für ein RAG mit 200.000 Dokumenten und ein paar Anfragen pro Sekunde ist das über-dimensioniert.
Azure AI Search: managed, mit Reranking und Agentic Retrieval
Azure AI Search nimmt Ihnen den Betrieb ab und liefert Retrieval-Funktionen, die Sie bei pgvector und Qdrant selbst bauen müssten. Der Dienst kombiniert Vektorsuche, Keyword-Suche (BM25) und einen semantischen Reranker in einer Managed-Umgebung. Wer ohnehin in Azure sitzt und Embeddings über Azure OpenAI (text-embedding-3-large) erzeugt, hat die kürzeste Strecke zur produktiven Lösung.
Der für RAG wichtigste Neuzugang: Agentic Retrieval ist über die REST-API-Version 2026-04-01 allgemein verfügbar. Statt einer einzelnen Vektorsuche zerlegt ein LLM komplexe Fragen in fokussierte Teil-Anfragen, führt sie parallel aus, reranked jede semantisch und fügt sie zu einer Antwort zusammen. Für agentische RAG-Muster, bei denen ein Agent mehrere Wissensfragen hintereinander stellt, ist das genau die Retrieval-Mechanik, die man sonst selbst orchestriert.
Der Haken ist der Preis, in Euro und in Souveränität. Azure AI Search kostet ab dem Standard-Tier deutlich mehr als eine selbst betriebene pgvector-Instanz, und die Daten liegen in der Azure-Region, nicht im eigenen Rechenzentrum. Für regulierte Häuser mit strenger Datenhaltung ist das der Knackpunkt, für Teams mit knapper Ops-Kapazität ist der Managed-Betrieb genau das Argument.
Welche RAG Vektordatenbank wofür: die Entscheidungsmatrix
Die kurze Antwort: Wählen Sie nach Ausgangslage, nicht nach Benchmark. Postgres im Haus plus moderate Skala führt zu pgvector. Hohe Skala plus harte Filter plus Self-Hosting führt zu Qdrant. All-in Azure plus wenig Ops führt zu Azure AI Search. In der Praxis landen unsere Mittelstands-Kunden mehrheitlich bei pgvector, weil das zweite System selten seinen Betrieb wert ist.
Diese Zeilen kann kein Benchmark für Sie beantworten, weil es keine kontextfreie beste Datenbank gibt. Ein Häufigkeitsfehler in Projekten: Teams starten mit Azure AI Search wegen Time-to-Production und merken erst spät, dass die Datenhaltung ihre Compliance verletzt. Wenn Sie den breiteren Marktüberblick über Alternativen wie Weaviate, Milvus oder Chroma brauchen, hilft unser Vektordatenbanken-Vergleich mit acht Lösungen.
Kosten und Betrieb: der ehrliche Teil
Die reine Lizenz ist bei pgvector und Qdrant null, bei Azure AI Search fließt sie in den Service-Preis. Der eigentliche Kostenblock im Enterprise-RAG ist aber nicht die Datenbank, sondern Embeddings, Reranking und Betrieb. Eine pgvector-Instanz bei Mittelstands-Volumen liegt oft im niedrigen dreistelligen Euro-Bereich pro Monat, ein Standard-Azure-AI-Search-Index deutlich darüber.
In unseren Projekten ist die teuerste Zeile fast nie die Vektor-DB, sondern die Iteration an der Retrieval-Qualität: Chunking, Hybrid-Gewichtung, Reranking, Evaluierung. Wer dort spart und die vermeintlich billigste DB nimmt, zahlt es in schlechten Antworten und Nacharbeit zurück.
Häufig gestellte Fragen
Was kostet eine RAG Vektordatenbank im Monat?
Die Datenbank selbst ist der kleinere Posten. pgvector läuft bei Mittelstands-Volumen oft für 150-400 EUR Infrastruktur pro Monat, ein self-hosted Qdrant eher 300-900 EUR plus GPU, ein Azure-AI-Search-Standard-Index ab rund 900 EUR. Der dominante Kostenblock im RAG ist Embeddings, Reranking und die Betriebszeit für Retrieval-Tuning.
Qdrant vs pgvector: was ist der Unterschied für RAG?
pgvector lebt in Ihrer bestehenden PostgreSQL-Datenbank und ist ideal bis in den Millionen-Bereich mit moderater Last. Qdrant ist ein eigenes, in Rust gebautes System für hohe Skalierung und anspruchsvolles Filtern, mit ACORN gegen Recall-Verlust bei Filtern und starker Quantisierung. Faustregel: pgvector, solange es reicht, Qdrant, wenn Skala oder Filter es erzwingen.
Ist Azure AI Search DSGVO-konform nutzbar?
Technisch ja, in einer EU-Region betrieben. Der Punkt ist nicht die Konformität an sich, sondern die Datenhaltung: Die Vektoren und oft die Quelltexte liegen in Azure, nicht im eigenen Rechenzentrum. Für Häuser mit strenger Souveränitätsvorgabe (Teile von Banking, Versicherung, öffentlicher Sektor) ist genau das der Grund, self-hosted mit pgvector oder Qdrant zu bleiben.
Welche Datenbank ist die beste für agentisches RAG?
Für Agentic Retrieval out of the box ist Azure AI Search am weitesten: Die Multi-Query-Zerlegung mit paralleler Ausführung und Reranking ist seit der API-Version 2026-04-01 allgemein verfügbar. Mit Qdrant oder pgvector bauen Sie diese Orchestrierung selbst, was mehr Kontrolle und Souveränität gibt, aber Eigenleistung im Retrieval-Layer bedeutet.
Kann ich später von pgvector zu Qdrant wechseln?
Ja, und das ist ein valider Plan. Wenn die Retrieval-Schicht sauber abstrahiert ist, tauschen Sie die Vektor-DB aus, ohne die RAG-Logik anzufassen. Wir starten bei passenden Kunden bewusst mit pgvector und halten den Wechsel zu Qdrant offen, falls Skala oder Filteranforderungen wachsen. Genau deshalb gehört die Abstraktion von Anfang an in die Architektur.
Nächster Schritt
Die Datenbank-Frage ist in einer Woche entschieden. Die schwere Arbeit ist das Retrieval darüber: Hybrid-Suche, Reranking, Filter und Evaluierung, sodass die Antworten stimmen.
Verwandte Themen
