25.04.2026 AI Engineering 6 Minuten Lesezeit

Vector-Store-Konsolidierung: Das Betriebsmodell entscheidet

Die Wahl des Vektorspeichers entscheidet 2026 kein ANN-Benchmark mehr, sondern das Betriebsmodell. pgvector 0.8.2, wo Postgres bereits die Datenplattform ist. Qdrant 1.17 für gefilterte Suche und Speichereffizienz im großen Maßstab. Azure AI Search für verwaltete Azure-Landschaften mit hybrider Suche und Semantic Ranker. Mit Speicherrechnung, Datenresidenz und dem Fall ohne Vektordatenbank.

Die Wahl fällt vor dem Benchmark

Retrieval-Systeme sammeln Vektorspeicher an. Ein Pilot auf der einen Engine, ein Produktionsindex auf der nächsten, dazu eine dritte Instanz aus einem anderen Team. Im April 2026 gibt es dafür keine technische Begründung mehr. Die ausgereiften Engines setzen sämtlich HNSW mit vergleichbarer Recall- und Latenzcharakteristik um; die veröffentlichten Abstände sind vor Jahren geschlossen worden. Nicht konvergiert ist der Betrieb: Patchen, Abrechnung, Zugriffskontrolle, Auditierbarkeit. Konsolidierung ist damit eine Betriebsentscheidung und keine Frage der Retrieval-Qualität.

Bindend sind drei Fragen. Wo dürfen die Vektoren physisch liegen? Wer patcht den Prozess? Welches Team hat Rufbereitschaft? Drei Optionen decken nahezu jede Landschaft ab, die uns begegnet. Die Tabelle nennt die Zuordnung, die wir anwenden. Die folgenden Abschnitte nennen, was die jeweilige Option nicht leistet.

Betriebsrandbedingung	Option	Hybrid und Reranking	Datenresidenz
Postgres bereits im Produktivbetrieb	pgvector 0.8.2	RRF selbst in SQL; BM25 über Erweiterung	Dort wo die Datenbank ohnehin läuft
Eigenes Kubernetes	Qdrant 1.17	RRF und DBSF eingebaut; Late-Interaction-Rerank	Volle Kontrolle inklusive eigenem Rechenzentrum
Verwaltet aber souverän	Qdrant Hybrid Cloud	Wie selbst betriebenes Qdrant	Data Plane im eigenen Cluster; nur Telemetrie geht heraus
Azure-Landschaft mit Managed Identity	Azure AI Search 2026-04-01	Hybrid-RRF plus verwalteter Semantic Ranker	Regionsgebundene Azure-Ressource
Unter einhunderttausend Chunks	Kein dedizierter Speicher	Exakter Scan plus Postgres-Volltextsuche	Folgt der primären Datenbank

Ein Dokument kommt an — Scan, Mail oder Upload. 1/4

pgvector wenn Postgres die Datenplattform ist

pgvector 0.8.2 ist am 25. Februar 2026 erschienen. Die Erweiterung liefert HNSW- und IVFFlat-Indizes, den Typ halfvec mit zwei Byte je Dimension und Indizierung bis 4000 Dimensionen, Bit-Vektoren mit binary_quantize sowie sparsevec. Die folgenreichere Änderung kam mit 0.8.0: iterative Indexscans. Zuvor lieferte eine Abfrage aus ANN-Index und restriktiver WHERE-Klausel stillschweigend weniger Zeilen als angefordert. Heute läuft der Scan weiter, bis das Limit erfüllt ist. Diese eine Korrektur hat die meisten Produktionsüberraschungen beseitigt.

Was pgvector nicht liefert: hybride Suche und Reranking. Die Volltextsuche von Postgres liefert tsvector und ts_rank, kein BM25; BM25 setzt eine Fremderweiterung voraus. Reciprocal Rank Fusion schreiben und pflegen Sie selbst als Common Table Expression. Der Indexaufbau ist an maintenance_work_mem gebunden und wird langsam, sobald er auf Platte auslagert. Dafür liegen die Vektoren in derselben Transaktion, derselben Sicherung und demselben Rollenmodell wie die Fachdaten. Für die meisten Teams ist das der ausschlaggebende Punkt.

Qdrant für Filterung und Speichereffizienz

Qdrant 1.17 ist am 20. Februar 2026 erschienen. Das Argument ist die gefilterte Suche. Version 1.16 vom 19. November 2025 brachte ACORN: Fallen direkte Nachbarn durch den Filter, werden Nachbarn zweiter Ordnung besucht. Auf fünf Millionen Vektoren misst Qdrant mit ACORN 97,20 Prozent Genauigkeit bei 13,86 Millisekunden, ohne ACORN 53,34 Prozent bei 1,25 Millisekunden. Die schnelle Konfiguration ist die falsche. Gerade bei wenig selektiven Filtern degradiert naives HNSW unbemerkt.

Dieselbe Version führte Inline Storage ein: Quantisierte Vektoren liegen direkt in den HNSW-Knoten. Auf einer Million Vektoren ergibt das 211 Abfragen pro Sekunde bei 430 MiB gegenüber 20 ohne die Option und liegt damit nahe an den 334, die 530 MiB Arbeitsspeicher kosten. Die Query-API fusioniert nativ per RRF und DBSF, unterstützt Sparse-Vektoren mit eingebautem IDF und bietet Late Interaction über Multivektoren als Rerank-Stufe. Das Embedding-Modell wählt Qdrant nicht. Die Vektoren kommen weiterhin aus Ihrer Pipeline.

Azure AI Search für verwaltete Azure-Landschaften

Die stabile REST-API 2026-04-01 hat Knowledge Bases und Knowledge Sources allgemein verfügbar gemacht, dazu Index-Aliase, Markdown-Parsing-Modi und benutzerseitig zugewiesene verwaltete Identitäten für Indexer-Verbindungen. Hybride Suche ist eingebaut: BM25 und Vektorabfrage laufen parallel und werden per Reciprocal Rank Fusion zusammengeführt. Der Semantic Ranker bewertet die Trefferliste anschließend mit mehrsprachigen Modellen aus der Bing-Entwicklung neu und liefert Captions sowie optionale Answers. Nichts davon erfordert Infrastruktur in Ihrem Betrieb.

Die Grenzen sind klar benannt. Der Semantic Ranker bewertet ausschließlich die ersten 50 Treffer neu; er wiederholt die Abfrage nicht über dem Gesamtbestand. Ein Dokument, das die erste Stufe nicht erreicht, bleibt draußen. Jeder Kandidat wird auf höchstens 2048 Token zusammengefasst, davon 128 für Titel und 128 für Keywords. Die Feldreihenfolge in der Semantic Configuration ist damit eine Relevanzentscheidung. Abgerechnet wird nutzungsabhängig mit monatlichem Freikontingent, seit April 2026 getrennt von Agentic Retrieval, und nur in ausgewählten Regionen verfügbar.

Quantisierung und die Speicherrechnung

Rechnen Sie vor dem Benchmark. Zehn Millionen Chunks mit 1536 Dimensionen in float32 ergeben 61,4 GB reine Vektordaten. Die Dimensionierungsregel von Qdrant schlägt rund fünfzig Prozent für die HNSW-Verlinkung auf, also etwa 92 GB im Arbeitsspeicher. Skalare Quantisierung auf int8 senkt die Nutzlast auf 15,4 GB, binäre Quantisierung mit einem Bit auf 1,92 GB. Qdrant hat in 1.15 Varianten mit 1,5 und 2 Bit ergänzt, also 24-fache und 16-fache Kompression als Mittelweg. Diese Zahlen bestimmen die Instanzgröße.

Kompression ist verlustbehaftet, und die Hersteller sagen das auch. Microsoft dokumentiert int8 mit vierfacher und binäre Quantisierung mit bis zu 28-facher Reduktion, nicht mit den theoretischen 32, und gleicht den Verlust über Oversampling und Rescoring aus. Bei skalarer Quantisierung setzt Rescoring voraus, dass die Vektoren in voller Präzision erhalten bleiben; ein Teil der Einsparung entfällt damit. Bei binärer Quantisierung dürfen die Originale verworfen werden, das Rescoring nutzt dann das binäre Skalarprodukt. Entscheiden Sie Kompression und Rescoring gemeinsam, sonst ist die Speicherzahl fiktiv.

Warum synthetische QPS-Zahlen in die Irre führen

Öffentliche ANN-Benchmarks melden Recall gegen Abfragen pro Sekunde: statische Datensätze, keine Filter, ein Knoten, keine Payload, keine parallelen Schreibvorgänge, keine Mandanten. Produktives Retrieval kehrt jede dieser Bedingungen um. Jede Abfrage trägt einen Mandanten- oder Berechtigungsfilter, der Bestand wird während des Lesens geschrieben, und ein Index bedient viele Kunden. Die ACORN-Zahlen oben zeigen den Effekt am deutlichsten: Die zehnfach schnellere Konfiguration ist die unbrauchbare.

Durchsatz ist zudem selten die bindende Größe. In einer RAG-Anfrage dominiert die Generierung die Gesamtlatenz; zehn Millisekunden Unterschied in der Vektorabfrage verschwinden darin. Fehlender Recall unter einem restriktiven Filter verschwindet nicht, er wird unmittelbar als falsche Antwort sichtbar. Messen Sie auf Ihrem Korpus, mit Ihren Filtern, bei Ihrer Schreiblast. Alles andere ist Werbearithmetik.

Wann keine Vektordatenbank nötig ist

Das gehört klar gesagt, denn es spart am meisten Geld. Unterhalb von etwa einhunderttausend Chunks bleibt ein exakter Scan über eine pgvector-Spalte in der Regel im Latenzbudget, braucht keinen Index und verliert deshalb keinen Recall. Ist die Suche in Wahrheit ein Nachschlagen über Kennung, Mandant oder Datum, schlägt eine WHERE-Klausel auf einem gewöhnlichen B-Tree jede ANN-Struktur. Bei stichwortdichten Beständen liefert BM25 allein oft bessere Ergebnisse und ist gegenüber Prüfern erheblich leichter zu erklären.

Ein zweiter Datenspeicher ist keine Bibliothek. Er bringt eine Konsistenzgrenze, ein Sicherungskonzept, ein Berechtigungsmodell, einen Patch-Rhythmus und einen Migrationspfad für den Tag mit, an dem das Embedding-Modell wechselt. Wir führen eine dedizierte Engine ein, wenn gefilterter Recall, Speichereffizienz oder Mandantentrennung in Postgres nachweislich scheitern. Vorher nicht, und nicht wegen eines überzeugenden Benchmark-Diagramms.

Was wir für den Rest von 2026 erwarten

Das Unterscheidungsmerkmal ist bereits von der ANN-Qualität in den Betrieb gewandert: Mandantenfähigkeit, Speicherhierarchien, gefilterter Recall bei geringer Selektivität und Retrieval-Schnittstellen, die Agenten direkt aufrufen. Die Azure-Freigabe vom April 2026 zeigt das Muster. Der Index ist keine Komponente mehr, die Sie zusammenbauen, sondern ein verwalteter Retrieval-Dienst, den Sie aufrufen. Unabhängige Engines behalten das Feld, in dem Datenresidenz, Kosten je Gigabyte und Betrieb im eigenen Rechenzentrum den Ausschlag geben. Dieses Feld wird in Europa nicht kleiner.

Der eigentliche Migrationsaufwand liegt im Embedding-Modell, nicht im Speicher. Jeder Modellwechsel erzwingt eine Neuberechnung des Bestands und entwertet abgestimmte Indexparameter. Wir erwarten die nächste Wettbewerbsrunde beim Austausch von Vektorfeldern im laufenden Betrieb und beim inkrementellen Neuberechnen. Unsere Arbeitsannahme für den Rest von 2026: ein Postgres-basierter Speicher plus höchstens eine dedizierte Engine. Drei Speicher in einer Landschaft sind ein Prüfungsbefund.