Vektordatenbanken wählt man nach dem, was zuerst bricht

Fast jedes Retrieval-System sollte mit pgvector in dem Postgres starten, das ohnehin schon läuft, und die Auswahlfrage lautet nicht "welche Vektordatenbank ist am schnellsten", sondern "welcher Fehlermodus erreicht mich zuerst". Veröffentlichte Recall- und QPS-Zahlen konvergieren über die Engines hinweg bei den Größenordnungen, in denen die meisten Teams tatsächlich arbeiten. Was nicht konvergiert, ist das, was passiert, wenn jede Query einen Tenant-Filter bekommt, wenn der Index während der Geschäftszeiten neu gebaut werden muss oder wenn der HNSW-Graph nicht mehr in den RAM passt. Das sind die Ereignisse, die eine Migration erzwingen, und jede Engine scheitert an einem anderen.

Der ehrliche Weg, Vector Stores zu vergleichen, ist also, vom Bruch aus rückwärts zu arbeiten. Man wählt den Ausfall, den man zuerst treffen wird, und dann die Engine, die ihn nicht hat. Alles andere ist ein Feature-Raster.

Die vier Dinge, die tatsächlich brechen

In produktiven RAG- und Agent-Memory-Systemen erklären vier Symptome fast jede Migration weg von der ursprünglichen Wahl:

• Index-Build- und Rebuild-Zeit. Man wechselt das Embedding-Modell, die Dimension oder den Distanzoperator, und jetzt muss ein Approximate-Nearest-Neighbour-Index über jede Zeile neu gebaut werden. Bei einer Million Vektoren ist das eine Kaffeepause. Bei fünfzig Millionen ist es ein Wartungsfenster, und man muss entscheiden, ob der alte Index Traffic bedient, während der neue gebaut wird.
• Recall bei gefilterter Suche. Kaum jemand fährt in Produktion eine ungefilterte Vektor-Query. Echte Queries lauten "nearest neighbours where tenant_id = X and status = active and updated_at > Y". Graph-Indizes sind für den ungefilterten Fall gebaut, und ein selektiver Filter kann dazu führen, dass eine ANN-Suche weniger als die angeforderten k Zeilen zurückgibt, und zwar still. Das ist ein Korrektheitsproblem im Kostüm eines Relevanzproblems.
• Graph-Speicher gegen RAM. HNSW ist ein Graph und will im Speicher leben. Sobald der Graph plus Working Set das übersteigt, was die Instanz hat, degradiert die Latenz nicht sanft, sie fällt von der Klippe, weil die Maschine bei jedem Probe Index-Seiten von der Platte liest.
• Freshness-Lag unter Schreiblast. Agent Memory und Support-Tooling schreiben permanent. Jeder Insert mutiert den Graphen, die Index-Wartung konkurriert mit dem Query-Traffic, und die Lücke zwischen "wir haben den Fakt gespeichert" und "der Fakt ist abrufbar" wird zu einer Frage der Korrektheit statt des Gefühls.

Man beachte, was nicht auf dieser Liste steht: rohe Queries pro Sekunde. Wer Retrieval an ein Modell liefert, das danach zwei Sekunden generiert, für den ist ein Unterschied von zehn Millisekunden in der Suchlatenz Rauschen. The latency that hurts in RAG lives in the number of round trips, nicht im ANN-Probe.

pgvector: der korrekte Default, und seine echten Obergrenzen

Das Argument für pgvector ist nicht, dass es Benchmarks gewinnt. Es ist, dass die Embeddings in derselben Transaktion leben wie die Zeile, die sie beschreiben, dass die Filter gewöhnliches SQL gegen Spalten sind, die bereits Indizes haben, dass Backup und Point-in-Time-Recovery genau die Story sind, die man ohnehin schon betreibt, und dass der On-Call bereits weiß, wie man EXPLAIN liest. Diese Kombination ist eine Menge p99 wert.

Die Obergrenzen sind spezifisch und lohnen das Auswendiglernen, denn die vage Angst vor ihnen verursacht mehr verfrühte Migrationen, als die Obergrenzen selbst es je tun:

• Dimensionslimits sind Indexlimits, keine Spaltenlimits. Eine vector-Spalte akzeptiert bis zu 16.000 Dimensionen, aber HNSW und IVFFlat indizieren nur bis 2.000. Mit halfvec (16-Bit-Floats) indiziert man bis zu 4.000 Dimensionen bei rund halbem Speicherbedarf. bit indiziert bis zu 64.000 Dimensionen für binäre Quantisierung, und sparsevec verarbeitet bis zu 1.000 Nicht-Null-Elemente. Ein Embedding mit 3.072 Dimensionen ist kein Grund, Postgres zu verlassen, sondern ein Grund, im Index-Ausdruck nach halfvec zu casten.
• Gefilterte Queries sind seit 0.8.0 keine Klippe mehr. Der alte Ausfall war real: Ein HNSW-Scan lieferte seine ef_search-Kandidaten, die WHERE-Klausel löschte die meisten davon, und man bekam drei Zeilen zurück, obwohl man zehn wollte. pgvector 0.8.0 hat iterative Index-Scans eingeführt, die weiterscannen, bis genug überlebende Zeilen zusammen sind. hnsw.iterative_scan = strict_order erhält die exakte Distanzreihenfolge, relaxed_order tauscht etwas Ordnung gegen besseren Recall. Wer pgvectors Filtering noch mit dem Stand von 2024 im Kopf hat, ist nicht mehr aktuell.
• Build-Speicher ist das, was wirklich beißt. HNSW baut im Speicher, wenn der Graph in maintenance_work_mem passt, und fällt auf einen deutlich langsameren On-Disk-Pfad zurück, wenn nicht. Die Abhilfe ist, den Wert für den Build zu erhöhen und parallele Worker zu nutzen, aber ab einer gewissen Größe plant man einen Rebuild, statt einen laufen zu lassen.
• Noisy Neighbours sind ein Architekturthema. Ein ANN-Build, der die CPU auf der Instanz sättigt, die den Checkout-Flow bedient, ist der Fehlermodus, der nichts mit Vektoren zu tun hat. Ein Read Replica oder eine separate Instanz löst das, und das ist auch der Moment, in dem pgvector aufhört, gratis zu sein.

Speziell auf AWS ist Aurora PostgreSQL mit pgvector ein erstklassiger Vector Store für Bedrock Knowledge Bases, die Wahl kostet also keine Managed-RAG-Features. Die Kostenseite davon habe ich in the OpenSearch Serverless to Aurora migration post aufgeschrieben, mit einem Vorbehalt weiter unten: Die OpenSearch-Seite dieses Vergleichs hat sich im Mai 2026 geändert.

OpenSearch: man kauft eine Suchmaschine, also sollte man sie als solche nutzen

OpenSearch rein als Vector Store zu wählen ist der teure Weg zu Vektorsuche. Es zu wählen, weil man Suche braucht und Vektoren eines der Dinge sind, mit denen man sucht, ist eine andere und deutlich bessere Entscheidung.

Was es liefert, was ein reiner Vector Store nicht liefert: echte lexikalische Suche neben ANN, sodass hybrides Retrieval aus BM25 und Vektorähnlichkeit eine Query ist, keine Architektur. Exaktes Keyword-Matching für die Teilenummern, Fehlercodes und Identifier, mit denen Embeddings bekanntermaßen schlecht umgehen. Aggregationen, Faceting und eine Filter-Engine, die für Attribute mit hoher Kardinalität gebaut wurde statt nachträglich angeschraubt. Und binäre Vektoren, die auf Bedrock Knowledge Bases nur die beiden OpenSearch-Optionen unterstützen.

Das Argument dagegen war historisch der Sockel: OpenSearch Serverless rechnete in OCUs ab, mit einem Produktionsminimum, das echtes Geld kostete, bevor ein einziges Dokument indiziert war. Auf diesem Argument baute mein Migrationspost auf, und es braucht eine Korrektur. Die nächste Generation von OpenSearch Serverless ist am 28. Mai 2026 allgemein verfügbar geworden, mit vollständig entkoppeltem Compute und Storage, Scale-to-Zero und einem Autoscaling, das AWS als zwanzigmal schneller als die Vorgängergeneration beschreibt. AWS nennt bis zu 60 Prozent Ersparnis gegenüber einem Cluster, das für Spitzenlast provisioniert wird. Wenn der Workload bursty ist, und agentisches Retrieval ist extrem bursty, gilt das alte Sockel-Argument nicht mehr in der Form, in der ich es vorgebracht habe.

Was weiterhin bricht: Es ist ein verteiltes System mit Shards, Replicas und einem Cluster State, und es wird irgendwann verlangen, über alle drei nachzudenken. Shard-Sizing für Vektor-Workloads ist nicht dasselbe wie für Logs. Und ein Rebuild ist ein Reindex, also Kapazitätsplanung für zwei Kopien des Index.

S3 Vectors: ein Storage-Tier, das Queries beantwortet, kein Serving-Tier

S3 Vectors hat am 2. Dezember 2025 die allgemeine Verfügbarkeit erreicht, mit dem Vierzigfachen der Preview-Skalierung: bis zu zwei Milliarden Vektoren pro Index und zehntausend Indizes pro Vector Bucket, im März 2026 kamen siebzehn weitere Regionen hinzu. AWS beziffert die Kostenreduktion gegenüber dem Betrieb einer Vektordatenbank auf bis zu 90 Prozent, und der Grund ist strukturell, nicht werblich: Es gibt kein Cluster, kein provisioniertes Compute und keine Idle-Kosten.

Die Zahl, die über die Eignung entscheidet, ist das Latenzprofil. AWS dokumentiert seltene Queries mit Antworten unter einer Sekunde und häufigere Queries bei rund 100 Millisekunden oder weniger. Das sollte man als Warm-Cache-Effekt lesen und dann ehrlich auf den eigenen Traffic schauen: Ein Support-Assistent, dem vierzig Fragen pro Stunde gestellt werden, hält nichts warm. Unter einer Sekunde ist fein für einen nächtlichen Summarisation-Job und falsch für einen interaktiven Chat, in dem das Modell danach noch seine eigenen zwei Sekunden braucht.

Wo es wirklich die richtige Antwort ist: kalte oder archivierende Vektor-Tiers, Per-Tenant-Indizes mit vielen Tenants und dünnem Traffic pro Tenant, kostengetriebene Bedrock Knowledge Bases mit tolerantem Latenzbudget, und alles, wo die Alternative ein bezahltes, aber untätiges Cluster war. Es fügt sich gut als zweites Tier unter einem Hot Store ein, und genau so würde ich es einsetzen, nicht als Komplettersatz.

Qdrant, Milvus, Pinecone: wenn der Payload gewinnt

Postgres verlässt man in Richtung einer dedizierten Engine, wenn der Vektor-Workload aufgehört hat, ein Feature der Anwendung zu sein, und zur Anwendung geworden ist. Drei Ausprägungen davon:

Qdrant ist die Wahl, wenn Filtering das Problem ist. Seine Payload-Indizes und das filterbare HNSW sind für den Fall gebaut, den pgvectors iterativer Scan lediglich überlebt: hochselektive Filter auf jeder Query, bei hohen Raten. Es liefert außerdem skalare, Produkt- und binäre Quantisierung, der praktische Weg, einen großen Index im Speicher resident zu halten. Für einen mandantenfähigen Agent-Memory-Store mit Per-Tenant-Filtern auf jedem Read ist das ein vertretbarer Grund, eine weitere Datenbank zu betreiben.

Milvus ist die Antwort für den Milliardenmaßstab. Plattenbasierte Indizierung (DiskANN) heißt, das Working Set muss nicht in den RAM passen, und genau das verändert in dieser Größenordnung die Hardware-Rechnung. Der Preis ist operativ: Es ist ein verteiltes System mit getrennten Coordinator-, Query-, Data- und Index-Rollen, und es in Produktion zu betreiben ist zuerst eine Personalentscheidung und dann eine technische. Unter ein paar hundert Millionen Vektoren kauft diese Komplexität sehr wenig.

Pinecone ist die Kaufen-statt-Bauen-Option, und sie sollte bewertet werden wie jedes SaaS: nach der operativen Last, die sie abnimmt, nicht nach Latenz. Serverless-Pricing entkoppelt Storage von Reads und Writes ohne Idle-Kosten, was zu spitzenlastigen Workloads passt und kleine Deployments wirklich günstig macht. Was man aufgibt, ist Kontrolle über die Fehlermodi, dazu kommen Egress und Vendor-Kopplung. Es ist außerdem ein unterstützter Store für Bedrock Knowledge Bases, also kein Ausstieg aus dem AWS-managed RAG-Pfad.

Der Long Tail, in Kürze

Weaviate ist das, was einem Batteries-included-RAG-Store am nächsten kommt: eingebaute Vektorisierungsmodule, hybride Suche und ein Schema-first-Modell. Attraktiv, wenn man Meinungen mitgeliefert haben will, weniger, wenn die Embedding-Pipeline schon existiert. Chroma ist ein Prototyping-Werkzeug, das ehrlich dazu steht, und jedes ernsthafte Deployment, das ich gesehen habe, ist irgendwann davon wegmigriert. Redis mit Vektorähnlichkeit ist exzellent, wenn die Vektoren flüchtig sind, Sessions, kurzlebiges Agent Memory, semantische Caches, und furchtbar als System of Record. MongoDB Atlas Vector Search ist für Mongo, was pgvector für Postgres ist: richtig, wenn die Dokumente schon dort liegen, und ein schlechter Grund, Mongo einzuführen, wenn nicht. Sowohl Redis Enterprise Cloud als auch MongoDB Atlas sind unterstützte Stores für Bedrock Knowledge Bases.

Die Entscheidungstabelle

Die Trigger, die wirklich "jetzt raus aus pgvector" bedeuten

Nicht Skalierung im Abstrakten. Diese:

• Der HNSW-Rebuild passt in kein akzeptables Wartungsfenster mehr, obwohl maintenance_work_mem bereits erhöht ist und parallele Worker im Einsatz sind.
• Der gefilterte Recall bleibt auch nach aktivierten iterativen Scans und getuntem ef_search zu kurz, weil die Filter selektiv genug sind, dass der Graph die falsche Struktur ist.
• Das Working Set des Index übersteigt den Instanzspeicher, und die nächstgrößere Instanz kostet mehr, als eine dedizierte Engine kosten würde.
• Die Vektorsuche hungert den transaktionalen Workload aus, und ein Read Replica ist nicht genug Trennung.
• Hybrides Ranking aus lexikalisch plus Vektor wird als First-Class-Query gebraucht, nicht als zwei Suchen, die im Anwendungscode gemerged werden. Dieser Punkt zeigt konkret auf OpenSearch.

Trifft nichts davon zu, ist die geplante Migration eine Vorliebe, kein Erfordernis. Das Team, das eine funktionierende Retrieval-Schicht auf der Datenbank ausliefert, die es ohnehin betreibt, und erst umzieht, wenn einer dieser Trigger feuert, erreicht Produktion deutlich früher als das Team, das den ersten Sprint mit Auswählen verbracht hat.

Das Fazit

Mit pgvector starten und seine vier Obergrenzen präzise genug kennen, um ein echtes Limit von Folklore zu unterscheiden. Zu OpenSearch wechseln, wenn Suche gebraucht wird statt Ähnlichkeit, und den Kostenvergleich gegen das Next-Generation-Serverless-Angebot neu rechnen statt gegen den alten OCU-Sockel. S3 Vectors als Cold Tier und für dünn besetzte Per-Tenant-Indizes nutzen, nicht als interaktiven Serving-Pfad. Zu Qdrant greifen, wenn Filtering dominiert, zu Milvus jenseits des Punkts, an dem der RAM die Rechnung bestimmt, und zu Pinecone, wenn man den Betrieb lieber kauft als führt. Nach dem Bruch wählen, der zuerst kommt, denn das ist die einzige Variable in diesem Vergleich, die sich zwischen den Engines nennenswert unterscheidet.

Weiterlesen

• Agent Memory Is a Database Problem, Not a Prompt Problem, darüber, warum die Speicherschicht entscheidet, was der Agent sich merken kann.
• Knowledge Base Chunking Is Where Your RAG Quality Dies, über das Retrieval-Problem, das keine Vektordatenbank für einen löst.

Für die Infrastrukturseite, Postgres und Suchcluster in Produktion zu betreiben, liegen die Cloud Field Notes auf ercan.cloud, und der Hub ist ercanermis.com.

Referenzen

• pgvector on GitHub, vector types, index types, and dimension limits.
• pgvector 0.8.0 release announcement, iterative index scans and filtering improvements.
• The next generation of Amazon OpenSearch Serverless is now generally available, AWS What's New, 28 May 2026.
• Amazon S3 Vectors is now generally available with 40 times the scale of preview, AWS What's New, 2 December 2025.
• Working with S3 Vectors and vector buckets, Amazon S3 User Guide.
• Prerequisites for using a vector store you created for a knowledge base, Amazon Bedrock User Guide.
• Approximate k-NN search, OpenSearch documentation.
• Filtering, Qdrant documentation.
• DiskANN-based on-disk index, Milvus documentation.
• Pinecone pricing, serverless read unit, write unit, and storage model.