Vektor-Datenbanken 2026: Milvus 3.0, Qdrant und die Postgres-Frage

📷 "Want your democracy back? Do two things. Vote and contact your representatives." by DonkeyHotey is licensed under CC BY 2.0. To view a copy of this license, visit https://creativecommons.org/licenses/by/2.0/.

Wer 2026 eine RAG-Pipeline in Produktion bringt, kommt an Vektor-Datenbanken nicht vorbei: Sie sind das Rückgrat der Retrieval-Augmented Generation, der dominierenden Enterprise-KI-Architektur. Doch die Kategorie ist in einem tiefgreifenden Umbruch. Im Juli 2026 hat Zilliz mit Milvus 3.0 eine Architektur vorgestellt, die Vektor-Retrieval direkt im Data Lake betreibt; Qdrant hat im März eine 50-Millionen-Dollar-Series-B abgeschlossen und wächst mit Agent-Workloads; und PostgreSQL mit pgvector übernimmt einen immer größeren Teil der kleineren Use Cases. Die Frage von 2024 – „Welche Vektor-Datenbank ist die beste?“ – ist 2026 die falsche. Entscheidend ist, welche Retrieval-Architektur zum eigenen Workload passt.

Milvus 3.0: Retrieval direkt im Data Lake

Zilliz hat Milvus 3.0 im Juli 2026 als „landmark release“ angekündigt. Der Kern: eine Lake-native-Architektur, die produktive Indexe und Retrieval direkt über Daten in Objekt-Storage (S3, Google Cloud Storage, Azure Blob Storage) aufbaut – ohne die Daten vorher in ein separates System zu kopieren. Bisher übliche Doppelhaltung (eine Kopie für Online-Retrieval, eine für Offline-Verarbeitung) samt Export- und Sync-Pipelines soll damit entfallen.

Daneben erweitert Milvus 3.0 die Engine über klassische Top-K-Suche hinaus: Server-seitiges Sortieren, Aggregation und facettierte Suche kombinieren semantische Relevanz mit Attributen wie Aktualität oder Kategorie. Mit „StructList“ unterstützt die Datenbank Multi-Vektor-Retrieval für Dokumente oder Bilder und damit auch Late-Interaction-Modelle wie ColBERT und ColPali. Der Sparse-Index wurde laut Zilliz intern etwa dreimal kleiner bei vergleichbarer Recall-Qualität. Milvus bleibt Apache-2.0-lizenziert und ist als graduiertes LF-AI-&-Data-Projekt weiterhin auf Kubernetes oder Docker lauffähig – auch in Air-Gapped-Umgebungen. Das Projekt meldet mehr als 45.000 GitHub-Sterne und über 100 Millionen Docker-Pulls.

Qdrant: Wachstum, TurboQuant und Agent-Workloads

Qdrant hat am 12. März 2026 eine Series B über 50 Millionen US-Dollar abgeschlossen und dabei mehr als 250 Millionen Downloads sowie Version 1.17 gemeldet. Bis Juni 2026 wuchs die GitHub-Community auf rund 32.400 Sterne. Im August 2026 folgte Qdrant 1.19 mit dem neuen TurboQuant-Datentyp und Speicher-Tiers, die Vektoren deutlich kompakter ablegen sollen.

Interessant ist vor allem, wohin Qdrant eingesetzt wird: TripAdvisor indexiert nach eigenen Angaben mehr als eine Milliarde multimodaler Nutzerbewertungen, HubSpot betreibt seinen Breeze-Assistenten darauf, und Bayer hat im August 2026 eine Enterprise-Suche mit 135 Millionen Punkten und Hybrid Search auf Qdrant vorgestellt – bei rund 20 Prozent Effizienzgewinn. Der gemeinsame Nenner dieser Use Cases: schreib-lastige, agentische Workloads. KI-Agenten erzeugen laut Analysen rund zehnmal so viele Suchanfragen wie Menschen – und sie schreiben kontinuierlich neue Vektoren, was read-optimierte, klassische RAG-Indexe zunehmend unter Druck setzt.

Die Postgres-Frage: pgvector bis 50 Millionen Vektoren

Parallel konsolidiert sich das untere Marktsegment rund um PostgreSQL. Mit pgvector (eine CREATE EXTENSION vector; entfernt) bekommen Teams Vektor-Suche in ihrer bestehenden Datenbank – inklusive ACID-Transaktionen und ohne Zusatz-System. Die Analyse von Actian (Q2 2026) sieht diese Kombination für Workloads unter rund 50 Millionen Vektoren als ausreichend, bei geschätzt 40 bis 60 Prozent geringeren Gesamtbetriebskosten gegenüber dedizierten Engines.

Die Grenze ist messbar: Bei einem TigerData-Benchmark gegen Qdrant erreichte pgvectorscale auf einem Datensatz mit 50 Millionen Vektoren den rund elffachen Durchsatz (471 vs. 41 Queries pro Sekunde) – Qdrant lag dafür bei der p95-Latenz (36,7 ms vs. 60,4 ms) und beim Index-Aufbau (3,3 vs. 11,1 Stunden) vorn. Jenseits von 50 Millionen Vektoren, so der Tenor, übernehmen dedizierte Engines: Sie sharden über Knoten, lagern Indexe auf Disk aus und halten die Latenz auch unter kontinuierlichen Schreiblasten stabil – Fähigkeiten, die eine relationale Datenbank mit Vektor-Datentyp nicht ohne Weiteres mitbringt.

Hybrid Search und Agent Memory als neue Standards

Ein zweiter Trend betrifft die Abfrage selbst: Produktions-RAG-Systeme kombinieren heute selten reine Vektor-Suche, sondern Dense Retrieval mit Keyword-Suche (sparse/BM25) und Metadaten-Filtern in einer Query. Wer Hybrid Search braucht, landet realistisch bei Weaviate, Elastic, OpenSearch oder eben pgvector mit Volltext – reine Vektor-Engines sind dann nur noch die halbe Lösung.

Schließlich wandert die Kategorie in Richtung Agent Memory: dedizierte Datenbanken für agentische KI müssen schreib-lastig, low-latency und mandantenfähig sein – Anforderungen, die 2026 noch kein Anbieter vollständig gelöst hat. Dass der Elastic-CEO 2025 „Vector databases are a feature“ erklärte, während Marktforscher den Markt von 3,73 Milliarden Dollar (2026) auf 10,6 Milliarden Dollar (2032) wachsen sehen, ist dabei kein Widerspruch: Beides gilt, nur für unterschiedliche Segmente.

Fazit

Vektor-Datenbanken sterben nicht – sie differenzieren sich. PostgreSQL übernimmt den Bereich unter 50 Millionen Vektoren, dedizierte Engines wie Qdrant und Milvus bedienen Skala und agentische Workloads, und Milvus 3.0 verschiebt die Grenze, indem Retrieval dorthin zieht, wo die Daten bereits liegen. Für Teams heißt das: zuerst den eigenen Workload vermessen (Vektoranzahl, Schreiblast, Compliance), dann die Architektur wählen – und die eigene Pipeline (Chunking, Embeddings, Re-Ranking) mindestens genauso ernst nehmen wie die Datenbank dahinter.