Vektorindex für Enterprise-RAG: Azure AI Search, pgvector oder Qdrant

TL;DR

Bei den Datenmengen, die im Mittelstand tatsächlich anfallen — meist unter fünf Millionen Textabschnitten — sind alle drei schnell genug. Die Entscheidung fällt über drei andere Fragen: Wer betreibt das Ding, wie kommen Berechtigungen in den Filter, und wo liegen die Daten. Für Häuser mit vorhandenem PostgreSQL ist pgvector meist die richtige Antwort, und sie wird zu selten gegeben.

Die Frage, die vor der Produktauswahl steht

Bevor Sie drei Datenbanken vergleichen, klären Sie eine Zahl: Wie viele Textabschnitte werden es tatsächlich?

Eine übliche Rechnung für ein produzierendes Unternehmen mit 400 Mitarbeitern: 30.000 Dokumente aus SharePoint, Netzlaufwerken und dem Qualitätsmanagement, im Schnitt 12 Seiten, pro Seite drei Abschnitte. Macht rund eine Million Vektoren. Bei 1.024 Dimensionen und Float32 sind das etwa 4 GB reine Vektordaten.

Eine Million Vektoren ist für jede der drei Optionen unauffällig. Es ist auch für PostgreSQL unauffällig. Die Benchmarks, die im Netz kursieren und bei 100 Millionen Vektoren Unterschiede um Faktor fünf zeigen, beschreiben eine Situation, in die Sie mit hoher Wahrscheinlichkeit nie kommen.

Deshalb: Lassen Sie die Geschwindigkeitsdiskussion. Sie ist bei Ihrer Größenordnung keine.

Was die drei tatsächlich unterscheidet

Die Zeile, die in Projekten die Entscheidung trägt, ist nicht die zur Geschwindigkeit, sondern die zum Betriebsmodell.

pgvector: die Antwort, die zu selten gegeben wird

Wenn in Ihrem Haus bereits ein PostgreSQL läuft — und in produzierenden Unternehmen ist das fast immer der Fall, unter irgendeiner Fachanwendung — dann ist pgvector eine Erweiterung, keine neue Komponente.

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE abschnitte (
    id            bigserial PRIMARY KEY,
    dokument_id   text NOT NULL,
    abteilung     text NOT NULL,       -- für Berechtigungsfilter
    freigabe_ab   date,
    inhalt        text NOT NULL,
    einbettung    vector(1024)
);

-- HNSW-Index: schneller bei der Suche, langsamer beim Aufbau
CREATE INDEX ON abschnitte
    USING hnsw (einbettung vector_cosine_ops)
    WITH (m = 16, ef_construction = 64);

-- Der Index, der in der Praxis genauso wichtig ist
CREATE INDEX ON abschnitte (abteilung);

Die Abfrage kombiniert Ähnlichkeit und Berechtigung in einer Anweisung:

SELECT inhalt, dokument_id,
       1 - (einbettung <=> $1) AS score
FROM abschnitte
WHERE abteilung = ANY($2)          -- Gruppen des angemeldeten Nutzers
  AND (freigabe_ab IS NULL OR freigabe_ab <= current_date)
ORDER BY einbettung <=> $1
LIMIT 8;

Das ist der eigentliche Vorteil, und er wird in Vergleichstabellen nie sichtbar: Ihre Berechtigungslogik ist normales SQL. Sie können sie mit den Tabellen verknüpfen, in denen ohnehin steht, wer zu welcher Abteilung gehört. Bei einer separaten Vektordatenbank müssen Sie diese Information duplizieren und synchron halten.

Wo pgvector an Grenzen stößt: Der HNSW-Index will in den Arbeitsspeicher. Bei einer Million Vektoren mit 1.024 Dimensionen reden wir über etwa 6 GB für Daten und Index — das ist auf einem vernünftig dimensionierten Datenbankserver kein Thema. Bei 50 Millionen wird es eines. Und die hybride Suche müssen Sie selbst bauen, indem Sie das Ergebnis einer Volltextsuche über tsvector mit dem Vektorergebnis verrechnen. Das sind etwa 40 Zeilen Code, keine Wissenschaft, aber eben Arbeit.

Unsere Position: Wenn Sie unter fünf Millionen Abschnitten bleiben und PostgreSQL im Haus haben, nehmen Sie pgvector. Eine zusätzliche Datenbank ist eine zusätzliche Sache, die ausfallen, veralten und gesichert werden muss.

Qdrant: wenn der Index ein eigenes Produkt wird

Qdrant lohnt sich, wenn der Vektorindex nicht nur Beiwerk einer Anwendung ist, sondern ein eigenständiger Dienst für mehrere Anwendungen.

Drei Dinge kann es besser als pgvector:

Hybride Suche ist eingebaut. Sparse-Vektoren für die stichwortartige Übereinstimmung und dichte Vektoren für die semantische, mit eingebauter Fusion der Ergebnisse. Bei technischen Dokumenten mit Teilenummern und Normbezeichnungen ist das kein Luxus — eine reine Vektorsuche findet "DIN EN ISO 9001" schlechter als eine Stichwortsuche.

Filter sind indexiert. Qdrant baut eigene Indizes auf Nutzlastfeldern und wendet den Filter während der Vektorsuche an, nicht danach. Bei restriktiven Berechtigungsfiltern — ein Nutzer darf nur 2 Prozent der Dokumente sehen — ist das ein spürbarer Unterschied zu einer nachgelagerten Filterung.

Mehrmandantenfähigkeit ist vorgesehen. Über Nutzlastfelder mit einer Mandanten-Kennung und entsprechend konfigurierte Segmente. Wie das bis auf Abschnittsebene aussieht, steht in der Anleitung zu Berechtigungen im Vektorspeicher.

from qdrant_client import QdrantClient, models

client = QdrantClient(url="https://qdrant.intern:6333", api_key=API_KEY)

# Nutzlast-Index auf dem Feld, nach dem gefiltert wird — ohne diesen
# Schritt filtert Qdrant zwar korrekt, aber deutlich langsamer
client.create_payload_index(
    collection_name="dokumente",
    field_name="abteilung",
    field_schema=models.PayloadSchemaType.KEYWORD,
)

treffer = client.query_points(
    collection_name="dokumente",
    query=frage_vektor,
    query_filter=models.Filter(must=[
        models.FieldCondition(key="abteilung",
                              match=models.MatchAny(any=nutzer_gruppen))
    ]),
    limit=8,
).points

Der Preis: ein weiterer Dienst. Eigene Sicherung, eigene Aktualisierung, eigene Überwachung. Wie eine Clusterinstallation aussieht, steht im Qdrant-Cluster-Leitfaden; die Sicherungsstrategie behandelt der Beitrag zu Backups für Vektordatenbanken.

Azure AI Search: teuer, aber Sie fassen es nie an

Azure AI Search ist der einzige der drei, bei dem Sie keinen Betrieb haben. Sie legen einen Dienst an, definieren ein Schema, schicken Dokumente hin.

Was es mitbringt und was Sie sonst selbst bauen müssten: hybride Suche mit semantischem Reranker, eine Indexierungspipeline mit Anbindern für Blob Storage, SharePoint und SQL, sowie eine Aufteilung in Abschnitte samt Einbettung als Teil des Dienstes.

Was dagegen spricht, in zwei Punkten:

Erstens der Preis. Die Stufen sind fix und beginnen bei einem niedrigen zweistelligen Monatsbetrag für die kleinste produktionstaugliche Konfiguration, bewegen sich für eine ernsthafte Installation aber im mittleren dreistelligen Bereich pro Monat — unabhängig davon, ob Sie den Index auslasten. Bei einer Million Abschnitten und moderater Abfragelast zahlen Sie für Kapazität, die Sie nicht brauchen. Prüfen Sie die aktuellen Stufenpreise für Ihre Region, sie ändern sich.

Zweitens die Datenlage. Ihre Dokumentinhalte liegen dann bei Microsoft. Für viele Häuser ist das geklärt, weil ohnehin M365 im Einsatz ist. Für Unternehmen in kritischer Infrastruktur oder mit Kundenverträgen, die Unterauftragsverarbeiter einschränken, ist es das nicht. Die Argumentationslinien dazu haben wir in der Einordnung souveräner KI sortiert.

Wo es klar gewinnt: wenn Ihre Quellen ohnehin in SharePoint und Azure Blob Storage liegen und Sie keine Person haben, die eine Ingestion-Pipeline baut und pflegt. Der Anbinder erledigt das, und das ist mehr Arbeit, als es klingt.

Die Entscheidung in drei Fragen

Statt einer Bewertungsmatrix drei Fragen, die in dieser Reihenfolge zu beantworten sind:

1. Dürfen die Dokumentinhalte das Haus verlassen? Nein → Azure AI Search fällt raus.
2. Läuft bereits ein PostgreSQL, und bleiben Sie unter fünf Millionen Abschnitten? Ja → pgvector, fertig.
3. Brauchen mehrere Anwendungen denselben Index, oder brauchen Sie hybride Suche ohne Eigenbau? Ja → Qdrant.

Bleibt alles offen, nehmen Sie pgvector und wechseln später. Der Wechsel ist unangenehm, aber überschaubar: Die Einbettungen bleiben dieselben, Sie schreiben einen Import. Was Sie nicht wechseln können, ohne alles neu zu berechnen, ist das Einbettungsmodell. Diese Entscheidung verdient mehr Aufmerksamkeit als die Wahl der Datenbank.

Häufig gestellte Fragen

Ist pgvector schnell genug für ein Unternehmens-RAG?

Bis in den Bereich weniger Millionen Abschnitte ja, mit HNSW-Index und ausreichend Arbeitsspeicher. Die Benchmarks, in denen spezialisierte Vektordatenbanken deutlich davonziehen, arbeiten mit zweistelligen Millionenzahlen. Ein mittelständisches Dokumentenkorpus aus 30.000 Dateien landet bei etwa einer Million Abschnitten — dort liegen die Antwortzeiten bei beiden Ansätzen im niedrigen zweistelligen Millisekundenbereich.

Was kostet Azure AI Search im Monat?

Der Dienst wird in festen Stufen abgerechnet, nicht nach Verbrauch. Die kleinste produktionstaugliche Stufe liegt im niedrigen zweistelligen Bereich pro Monat, eine Konfiguration mit semantischem Reranker und mehreren Replikaten im mittleren dreistelligen. Da sich die Preise je nach Region und Stufe ändern, prüfen Sie sie vor der Entscheidung in der offiziellen Preisübersicht — und rechnen Sie gegen die Personalkosten, die eine selbst betriebene Alternative verursacht.

Wie bilde ich Berechtigungen im Vektorindex ab?

Über Metadatenfelder, die bei jeder Abfrage als Filter mitgegeben werden — typischerweise eine Liste von Gruppen oder Abteilungen. Wichtig ist, dass der Filter während der Suche greift und nicht danach: Bei nachgelagerter Filterung bekommen Sie zu wenige Treffer zurück, wenn ein Nutzer nur einen kleinen Teil des Bestands sehen darf. pgvector löst das über normales SQL, Qdrant über indexierte Nutzlastfelder.

Kann ich später von pgvector zu Qdrant wechseln?

Ja, und der Wechsel ist weniger aufwendig als befürchtet: Die Vektoren selbst bleiben unverändert, Sie exportieren sie mit ihren Metadaten und importieren sie in die neue Sammlung. Aufwendig ist nur das, was Sie in SQL gebaut haben und in der Filtersprache der Zieldatenbank nachbilden müssen. Nicht wechselbar ohne Neuberechnung ist dagegen das Einbettungsmodell.

Brauche ich hybride Suche?

Wenn Ihre Dokumente Bezeichner enthalten — Teilenummern, Normbezeichnungen, Fehlercodes, Artikelnummern — dann ja. Eine reine Vektorsuche findet exakte Zeichenketten schlechter als eine Stichwortsuche, weil die Einbettung genau diese Genauigkeit wegabstrahiert. Bei reinen Fließtexten wie Richtlinien oder Handbüchern reicht die Vektorsuche allein.

Der nächste Schritt

Zählen Sie, wie viele Abschnitte Ihr Korpus tatsächlich ergibt: Dokumente mal durchschnittliche Seitenzahl mal drei. Wenn Sie unter fünf Millionen landen und PostgreSQL im Haus haben, ist die Entscheidung gefallen, und Sie sparen sich die Evaluierung. Bei der Auslegung der Pipeline dahinter unterstützen wir gern.