Weaviate, OpenSearch und PostgreSQL mit pgvector im Vergleich für Vektor- und Hybrid-Suche

Wenn eine Anwendung Suchfunktionen benötigt, kommen häufig Werkzeuge infrage, die bereits Teil der vorhandenen Infrastruktur sind. Dazu gehören beispielsweise OpenSearch für die Volltextsuche oder PostgreSQL mit der Erweiterung pgvector für Anwendungen, die auf relationalen Daten basieren. Beide Systeme können Vektoren speichern und durchsuchen, wurden jedoch ursprünglich nicht mit Vektoren als zentraler Datenstruktur entwickelt. OpenSearch ergänzt eine auf invertierten Indizes basierende Suchmaschine um Vektorsuche. pgvector stellt die Suche nach nächsten Nachbarn über SQL-Operatoren bereit. Das eignet sich gut, wenn ein Vektor lediglich eine von vielen Spalten ist, wurde aber nicht speziell für Anwendungen entwickelt, bei denen semantische Suche die zentrale Aufgabe darstellt.

Weaviate verfolgt einen anderen Ansatz. Der HNSW-Vektorindex (Hierarchical Navigable Small World) bildet dort eine zentrale Datenstruktur, während BM25-Schlüsselwortsuche und hybride Suche unmittelbar darum herum integriert sind. In der Praxis lassen sich semantische Suche, Schlüsselwortsuche und eine Kombination aus beiden jeweils mit einem einzelnen API-Aufruf durchführen. Wird Weaviate über eine verwaltete Datenbankplattform betrieben, können Aufgaben wie Bereitstellung, Backups, Cluster-Wartung und Software-Updates vom jeweiligen Dienstanbieter übernommen werden. Dadurch sinkt der operative Aufwand für Anwendungsteams.

Um den Vergleich greifbar zu machen, wird in diesem Artikel derselbe Bestand an Podcast-Transkripten in drei verwaltete Datenbankumgebungen geladen. Anschließend werden die Eigenschaften gegenübergestellt, die bei Suchanwendungen tatsächlich Unterschiede ausmachen. Dazu gehören die Ergebnisqualität bei Vektor-, Schlüsselwort- und Hybrid-Retrieval, der Umfang der Suchlogik innerhalb der Anwendung, die Geschwindigkeit beim Einlesen der Daten sowie die Größe der Indizes. Die reine Abfragegeschwindigkeit steht nicht im Mittelpunkt. In dieser Größenordnung reagieren alle drei Systeme ähnlich schnell, sodass die Abfragelatenz kein entscheidendes Unterscheidungsmerkmal darstellt.

Wichtigste Erkenntnisse

Die hybride Suche lieferte bei allen Engines die beste Qualität, während nur Weaviate sie mit einem einzelnen API-Aufruf ausführte. Die Kombination aus Vektor- und Schlüsselwort-Retrieval übertraf bei allen drei Systemen die jeweils allein verwendeten Verfahren. Weaviate erreichte mit hit@10 0.725 den höchsten Hybrid-Wert, gefolgt von OpenSearch mit 0.685 und PostgreSQL mit pgvector mit 0.665. Bei OpenSearch und pgvector erfordert hybrides Retrieval zwei Rankings sowie einen zusätzlichen Rank-Fusion-Prozess, der separat implementiert und gepflegt werden muss.

Die Qualität der Vektorsuche wird in erster Linie durch die Embeddings und nicht durch die Datenbank bestimmt. Nachdem die Tiefe der Kandidatenliste zwischen den Engines angeglichen worden war, lagen alle drei Systeme mit denselben Vektoren im Bereich von hit@10 0.575 bis 0.600.

Auch die betrieblichen Vorteile unterscheiden sich zwischen den Engines. Weaviate nahm die Daten am schnellsten auf, da HNSW- und BM25-Indizes gemeinsam in einem einzigen Ladeprozess erstellt wurden. pgvector benötigte den geringsten Speicherplatz und kam auf einen Index von 1.87 GB gegenüber 2.91 GB bei OpenSearch. Für konkurrenzfähige Ergebnisse bei der Schlüsselwortsuche war dort allerdings eine gezielte Konstruktion der Abfragen erforderlich.

Methodik

Der Datensatz bestand aus Transkripten von Podcast-Episoden aus 4,886 unterschiedlichen Folgen. Die Transkripte wurden in Abschnitte mit ungefähr 500 Tokens aufgeteilt, wodurch 100,000 Dokumente entstanden. Jedes Dokument enthielt den jeweiligen Textabschnitt zusammen mit Metadaten zur Episode. Die Embeddings wurden einmalig mit OpenAIs Modell text-embedding-3-small mit 1,536 Dimensionen erzeugt und anschließend zwischengespeichert. Dadurch blieb der Embedding-Prozess für alle drei Systeme identisch.

Alle drei Engines liefen als verwaltete Datenbankdienste und wurden von einer separaten Cloud-Compute-Instanz aus abgefragt.

In diesem Vergleich kommen hauptsächlich zwei Arten von Indizes vor. HNSW (Hierarchical Navigable Small World) ist eine graphbasierte Struktur für die Vektorsuche. Dabei wird jedes Embedding innerhalb eines mehrschichtigen Graphen mit benachbarten Embeddings verbunden. Anstatt eine Suchanfrage mit allen 100,000 Vektoren zu vergleichen, bewegt sich die Suchmaschine durch den Graphen und sucht dort nach Vektoren, die der Anfrage besonders nahe liegen. Dadurch wird die Suche schnell, wobei das Ergebnis näherungsweise und nicht vollständig exakt ist.

Ein invertierter Index ist die klassische Struktur für die Schlüsselwortsuche. Er ordnet einzelne Wörter den Textabschnitten zu, in denen sie vorkommen. Das ähnelt dem Stichwortverzeichnis eines Buches, das Begriffe bestimmten Seiten zuordnet. BM25 ist eine verbreitete Ranking-Formel, die Treffer unter anderem danach bewertet, wie selten ein Begriff ist und wie stark er innerhalb eines bestimmten Textabschnitts vorkommt. PostgreSQL deckt vergleichbare Aufgaben mit der HNSW-Implementierung von pgvector für Vektoren und einem GIN (Generalized Inverted Index) über tsvector ab. tsvector ist der native PostgreSQL-Datentyp für die Volltextsuche.

Dieser Vergleich ist nicht als kontrollierter Hardware-Benchmark gedacht. Die verwendeten Instanzen waren nicht mit identischen Spezifikationen ausgestattet. Direkte Aussagen über die reine Geschwindigkeit der Systeme werden deshalb bewusst vermieden. Im Mittelpunkt stehen stattdessen die Qualität der Ergebnisse und architektonische Unterschiede, die unabhängig von der konkreten Hardware relevant bleiben. Dazu gehört insbesondere, wie die einzelnen Systeme Daten abrufen und wie viel Suchlogik innerhalb der Anwendung implementiert werden muss.

Zur Messung der Retrieval-Qualität wurden zufällig 200 Textabschnitte aus dem Datensatz ausgewählt. Ein LLM (Large Language Model) erzeugte für jeden dieser Abschnitte eine natürliche Frage, die sich gezielt auf den jeweiligen Inhalt bezog. Anschließend wurden diese generierten Fragen als Suchanfragen verwendet, um zu prüfen, ob der ursprüngliche Abschnitt unter den zehn höchstplatzierten Ergebnissen erschien.

Eine erfolgreiche Suche wurde gezählt, wenn der Ausgangsabschnitt unter den ersten zehn Treffern vorkam. Daraus ergab sich die Metrik hit@10. Zusätzlich wurde der Mean Reciprocal Rank (MRR) erfasst. Dabei fällt der Wert höher aus, je weiter oben der relevante Abschnitt in der Ergebnisliste erscheint. Recall@10 wurde anhand einer exakten Brute-Force-Suche nach den nächsten Nachbarn über dieselben Vektoren bestimmt. Die Indexgröße entspricht dem Speicherbedarf auf dem Datenträger, nachdem der vollständige Datensatz geladen worden war.

Bei der Indexkonfiguration verwendeten Weaviate und pgvector HNSW mit Standardparametern. OpenSearch nutzte seine k-NN-Funktionalität mit der Lucene-HNSW-Engine und Kosinusähnlichkeit. Sämtliche Vektoren waren vorab berechnet und in allen Systemen identisch. Um eine möglichst sinnvolle Vergleichbarkeit zu erreichen, wurde jede Engine so konfiguriert, wie sie typischerweise für englischsprachige Inhalte eingesetzt werden könnte.

Der Schlüsselwortoperator von Weaviate ist technisch gesehen BM25F und unterstützt die Gewichtung mehrerer Felder. Wird jedoch lediglich ein einzelnes Inhaltsfeld durchsucht, entspricht das Verhalten dem klassischen BM25-Verfahren, das auch OpenSearch grundsätzlich verwendet. OpenSearch arbeitete mit dem englischen Analyzer für Stoppwortentfernung und Stemming. Dies entsprach der englischen Konfiguration von PostgreSQL sowie dem Tokenisierungsverhalten von Weaviate. OpenSearch wurde nach dem Laden außerdem entsprechend den Empfehlungen für die k-NN-Implementierung zusammengeführt. Die Tiefe der HNSW-Kandidatenliste, dargestellt durch ef_search, wurde für alle drei Systeme auf 100 vereinheitlicht. Dieser Wert entspricht dem Standard von Weaviate.

Datenaufnahme und Laden

Da die Embeddings bereits vorab berechnet worden waren, bestand der Ladeprozess in allen drei Systemen im Wesentlichen aus derselben Aufgabe: 100,000 Textabschnitte einfügen und sowohl einen Vektorindex als auch einen Schlüsselwortindex aufbauen. Weil die zugrunde liegenden Instanzen nicht mit identischer Hardware ausgestattet waren, sollten die konkreten Ladezeiten nicht als allgemeingültiger Hardware-Benchmark verstanden werden. Die beobachtete Reihenfolge mit Weaviate an erster Stelle, PostgreSQL an zweiter und OpenSearch an dritter Stelle spiegelt jedoch Unterschiede darin wider, wie die Engines ihre Indizes erstellen und verwalten.

Weaviate führt Datenaufnahme und Indexierung gemeinsam durch. Sobald ein Objekt über den gRPC-Batch-Endpunkt eintrifft, werden sowohl der zugehörige Knoten im HNSW-Graphen als auch der Eintrag im invertierten BM25-Index während desselben Vorgangs erzeugt. Nach Abschluss des Ladevorgangs kann die Collection unmittelbar durchsucht werden. Ein separater Indexierungsschritt muss weder gestartet noch geplant oder überwacht werden.

PostgreSQL trennt das Laden der Daten vom Aufbau der Indizes. Bulk-Inserts mit execute_values können Datensätze schnell in der Datenbank ablegen. Anschließend werden die HNSW- und GIN-Indizes in separaten Schritten erstellt. Bei diesem Datensatz mit vergleichsweise kleinen Textabschnitten dauerten die Indexierungsprozesse nur kurz. Bei größeren Datenmengen kann der Aufbau des HNSW-Indexes jedoch zum dominierenden Aufwand werden. Dieser Schritt muss gezielt gestartet, überwacht und bei jedem vollständigen erneuten Laden wiederholt werden.

OpenSearch verursacht während des Ladevorgangs wiederholt Indexierungsarbeit. Die k-NN-Strukturen werden neu aufgebaut, wenn Segmente während der Datenaufnahme zusammengeführt werden. Dadurch läuft die Pflege der Indizes parallel zum Bulk-Loading, wobei Teile der Arbeit mehrfach durchgeführt werden. In diesem Vergleich führte dieses Verhalten zur langsamsten Datenaufnahme der drei Systeme. Anpassungen wie größere Segmente oder verzögerte Refresh-Vorgänge können einen Teil dieser Zeit reduzieren, bringen jedoch zusätzliche Konfigurations- und Betriebsentscheidungen mit sich.

Der wesentliche Unterschied besteht daher nicht allein in der Geschwindigkeit der Inserts. Entscheidend ist, an welcher Stelle der Aufbau des Indexes erfolgt: automatisch während der Datenaufnahme bei Weaviate, als expliziter nachgelagerter Schritt bei PostgreSQL oder verteilt über den gesamten Ladeprozess bei OpenSearch.

Hybrid-Suche: Ein Aufruf gegenüber zwei Abfragen

Die Hybrid-Suche verbindet semantische Vektorrelevanz mit der Schlüsselwortrelevanz von BM25. In diesem Vergleich lieferte sie die stärkste Ergebnisqualität und machte zugleich einige der wichtigsten architektonischen Unterschiede zwischen den drei Systemen sichtbar. Praktisch entscheidend ist dabei, wie viel vom Retrieval-Ablauf innerhalb der Anwendung implementiert und gepflegt werden muss.

Weaviate unterstützt hybride Suche nativ mit einem einzelnen Aufruf. Dabei werden sowohl der HNSW- als auch der BM25-Index durchsucht, die jeweiligen Rankings mit Reciprocal Rank Fusion (RRF) kombiniert und anschließend als gemeinsame sortierte Ergebnisliste zurückgegeben. Der Parameter alpha bestimmt das Verhältnis zwischen beiden Suchmethoden. Ein Wert von 0 steht für reine Schlüsselwortsuche, während 1 ausschließlich Vektorsuche verwendet.

results = collection.query.hybrid(

query=query_text,

vector=query_vector,

alpha=0.5,

limit=10,

)

OpenSearch stellt in dieser Konfiguration keine native Hybrid-Abfrage bereit. Stattdessen werden eine Vektorabfrage und eine Schlüsselwortabfrage getrennt ausgeführt. Anschließend werden die beiden resultierenden Ranglisten innerhalb der Anwendung zusammengeführt.

knn = client.search(index=“passages“, body={

„size“: 50, „query“: {„knn“: {„embedding“: {

„vector“: query_vector, „k“: 50,

„method_parameters“: {„ef_search“: 100}}}}})

bm25 = client.search(index=“passages“, body={

„size“: 50, „query“: {„match“: {„transcript_text“: query_text}}})
def rrf(*result_lists, k=60): # you write, test, and maintain this

scores = {}

for results in result_lists:

for rank, hit in enumerate(results):

scores[hit[„_id“]] = scores.get(hit[„_id“], 0) + 1 / (k + rank + 1)

return sorted(scores, key=scores.get, reverse=True)[:10]
results = rrf(knn[„hits“][„hits“], bm25[„hits“][„hits“])

Auch pgvector bietet keine eigene Funktion für hybride Suche. Die entsprechende Zusammenführung zweier Ranglisten kann stattdessen unmittelbar in SQL umgesetzt werden.

WITH v AS (SELECT guid, row_number() OVER (ORDER BY embedding <=> %(qv)s) rk

FROM passages ORDER BY embedding <=> %(qv)s LIMIT 50),

k AS (SELECT guid, row_number() OVER (ORDER BY ts_rank(tsv, to_tsquery(‚english‘, %(q)s)) DESC) rk

FROM passages WHERE tsv @@ to_tsquery(‚english‘, %(q)s) LIMIT 50)

SELECT p.guid,

COALESCE(1.0/(60+v.rk),0) + COALESCE(1.0/(60+k.rk),0) AS rrf_score

FROM passages p LEFT JOIN v USING (guid) LEFT JOIN k USING (guid)

WHERE v.guid IS NOT NULL OR k.guid IS NOT NULL

ORDER BY rrf_score DESC LIMIT 10;

Der Unterschied geht über die Anzahl der Netzwerk-Round-Trips hinaus. Eine Architektur mit zwei Rankings erzeugt eine zusätzliche Wartungsfläche. Die Fusion-Logik wird Bestandteil des Anwendungscodes, muss getestet werden und sollte über sämtliche Dienste und Programmiersprachen hinweg konsistent bleiben, die Suchanfragen ausführen. Bei Weaviate lässt sich die Gewichtung durch die Änderung eines einzelnen Fließkommawerts anpassen. Bei den anderen Ansätzen hängt das entsprechende Verhalten von selbst verwalteter Fusion-Logik und Glättungskonstanten ab.

Suchqualität: Vektor-, Schlüsselwort- und Hybrid-Suche

Anhand der 200 im Methodikabschnitt beschriebenen generierten Fragen wurde jede Engine danach bewertet, ob der ursprüngliche Ausgangsabschnitt unter den zehn höchstplatzierten Ergebnissen auftauchte. Dafür wurde hit@10 verwendet. Zusätzlich wurde der Mean Reciprocal Rank (MRR) gemessen.

Drei Ergebnisse sind besonders relevant.

Hybrides Retrieval erzielte bei jeder Engine einen höheren hit@10-Wert als reine Vektor- oder reine Schlüsselwortsuche. Dies ist die unmittelbarste praktische Erkenntnis aus dem Vergleich. Wenn die Qualität des Retrievals entscheidend ist, bietet die Kombination beider Suchmethoden einen klaren Vorteil.

Die Qualität der Vektorsuche war bei allen drei Systemen nahezu identisch und bewegte sich zwischen hit@10 0.575 und 0.600. Das ist nachvollziehbar, weil alle Systeme dieselben Embeddings speicherten und sie nach der Vereinheitlichung der Kandidatentiefe mit sehr ähnlichen Recall-Werten zwischen 0.967 und 0.988 abriefen. Die Datenbank verbessert oder verschlechtert die semantischen Informationen innerhalb der Vektoren nicht. Ihre Aufgabe besteht darin, die passenden Vektoren zuverlässig zu finden.

Weaviate erzielte das stärkste Hybrid-Ergebnis und gleichzeitig den höchsten Gesamtwert mit hit@10 0.725 und MRR 0.504. Das Ergebnis spiegelt die Kombination aus nativer Fusion und BM25-Implementierung wider.

Die PostgreSQL-Volltextsuche erreichte zunächst einen Wert von 0.04, wenn plainto_tsquery verwendet wurde. Dabei müssen alle relevanten Wörter einer Frage übereinstimmen. Nachdem die Abfrage so umgebaut worden war, dass ihre Begriffe über to_tsquery und den Operator | mit OR kombiniert wurden, stieg der Wert auf 0.550. OpenSearch und Weaviate lieferten bereits mit ihren Standardkonfigurationen stärkere Ergebnisse bei der Schlüsselwortsuche, während PostgreSQL eine bewusst aufgebaute Textabfrage erforderte.

Wie die Ergebnisse bei einer einzelnen Suchanfrage aussehen

Aggregierte Kennzahlen können allein betrachtet abstrakt wirken. Deshalb ist es hilfreich zu untersuchen, was die Systeme bei einer konkreten Suchanfrage zurückgaben: how to handle rejection in sales. Da die indexierten Dokumente aus Textabschnitten mitten in Gesprächen bestanden, beginnen einige Resultate mitten in einem Satz.

Die Vektorsuche lieferte bei allen drei Engines dieselben drei führenden Ergebnisse, da in allen Systemen identische Embeddings gespeichert waren. Das stärkste Resultat stammte aus einem Interview mit Daniel Pink über sein Verkaufsbuch To Sell Is Human:

“…gonna get rejected, there’s no question about it. So one of the qualities that I talk about is a quality called buoyancy… every day I face an ocean of rejection. Okay, that’s what sales is like… So buoyancy is how do you stay afloat in that ocean of rejection?”

Die gewählte Datenbank entscheidet nicht darüber, welche semantischen Informationen ein Embedding-Modell erkennt. Dieses Verhalten wird hauptsächlich vom Embedding-Modell bestimmt. Die Datenbank beeinflusst stattdessen, wie zuverlässig die zugehörigen Vektoren abgerufen werden. Dieser Unterschied zeigt sich im Recall.

Auch die Schlüsselwortsuche führte bei dieser Anfrage an der Spitze zu weitgehend übereinstimmenden Ergebnissen. Alle drei Engines platzierten dieselben zwei Abschnitte auf den ersten Positionen: die Geschichte eines Vertriebsprofis über seine ersten Erfahrungen mit telefonischer Kaltakquise und eine Art-of-Charm-Frage eines Zuhörers über Angst bei Cold Calls. Unterschiede traten ab der dritten Position auf. Dort wählte jedes System einen anderen Abschnitt, wobei alle Ergebnisse weiterhin thematisch passend waren.

Die Abweichungen fallen nicht immer so gering aus. Bei einer weiteren der 200 Bewertungsfragen, “What should a presenter do if their audience starts leaving during their session?”, lieferte nur Weaviate den Textabschnitt zurück, aus dem die Frage ursprünglich erzeugt worden war. Die beiden anderen Systeme lieferten dagegen dasselbe falsche Ergebnis.

Feldgewichtung und Analyzer-Konfiguration entscheiden stärker als die BM25-Formel selbst darüber, ob die Schlüsselwortsuche im gewünschten Themenbereich bleibt. Die Schlüsselwortsuche bewertet Wörter, anstatt ihre Bedeutung zu verstehen. Deshalb haben die für das Ranking berücksichtigten Felder und Tokens einen erheblichen Einfluss.

Die Hybrid-Suche kombiniert semantische und lexikalische Signale. Bei der Anfrage zum Umgang mit Ablehnung im Vertrieb kamen alle drei Systeme auf dieselben drei führenden Abschnitte: die Cold-Calling-Geschichte des Vertriebsprofis, den Abschnitt von Daniel Pink über Buoyancy und die Frage zur Angst vor Cold Calls. Das entspricht dem allgemeinen Muster aus den aggregierten Ergebnissen. Die Vektorsuche bleibt über die verschiedenen Engines hinweg relativ konstant, die Schlüsselwortsuche zeigt stärkere Unterschiede und die Hybrid-Suche liefert bei praktischen Suchanfragen die zuverlässigsten Ergebnisse.

Indexgröße

Die folgenden Werte zeigen den Speicherbedarf, nachdem alle 100,000 Dokumente mit 1,536-dimensionalen Embeddings, Textabschnitten und Metadaten geladen worden waren.

pgvector benötigte den geringsten Speicherplatz. Das ist ein relevanter Vorteil, wenn Vektoren lediglich als eine Spalte innerhalb einer bestehenden relationalen Tabelle gespeichert werden. OpenSearch belegte unter anderem deshalb mehr Speicher, weil das rohe Embedding-Array zusätzlich zum k-NN-Graphen im Feld _source jedes Dokuments erhalten bleibt. Weaviate verwaltet ebenfalls einen HNSW-Graphen zusammen mit einem invertierten Index. Da die verwendete verwaltete Umgebung jedoch keine Angabe zur tatsächlichen Größe auf dem Datenträger bereitstellte, wurde dafür kein geschätzter Wert angegeben.

Wann welche Suchmaschine geeignet ist

Wann Weaviate sinnvoll ist

Weaviate ist eine geeignete Wahl, wenn semantische Suche oder Retrieval-Augmented Generation (RAG) die zentrale Arbeitslast darstellen. Native Hybrid-Suche, der in diesem Vergleich höchste beobachtete Durchsatz bei der Datenaufnahme und die stärkste Retrieval-Qualität machen es zu einer wartungsärmeren Option, wenn die Suche eine zentrale Rolle innerhalb der Anwendung spielt. Der alpha-Parameter ersetzt eine separate Fusion-Funktion samt zugehöriger Anwendungslogik. Bei der Bereitstellung über eine verwaltete Plattform kann Weaviate außerdem betrieben werden, ohne dass Indexverwaltungsprozesse direkt im Anwendungscode umgesetzt werden müssen.

Wann OpenSearch sinnvoll ist

OpenSearch eignet sich besonders für Umgebungen, in denen bereits ein OpenSearch-Cluster für Volltextsuche oder Log-Analyse betrieben wird und Vektorsuche schrittweise ergänzt werden soll. Ebenso ist es sinnvoll, wenn etablierte Funktionen wie Facettierung, Aggregationen und horizontale Skalierung benötigt werden. Die Ergebnisse sind konkurrenzfähig, allerdings erfordert hybrides Retrieval in dieser Konfiguration eine Orchestrierung innerhalb der Anwendung. Auch die Auswahl der k-NN-Engine kann Recall und Tuning deutlich beeinflussen, sodass diese Architekturentscheidung möglichst früh getroffen werden sollte.

Wann PostgreSQL mit pgvector sinnvoll ist

PostgreSQL mit pgvector ist besonders geeignet, wenn Vektoren gegenüber dem relationalen Datenmodell eine ergänzende Rolle spielen. Beispiele dafür sind Tabellen für Textabschnitte oder Produkte, bei denen ORDER BY embedding <=> $1 nur ein Teil neben mehreren WHERE-Bedingungen, JOIN-Operationen und transaktionalen Anforderungen ist. In diesem Vergleich benötigte die Lösung den geringsten Speicherplatz und hält Vektoren unmittelbar bei den relationalen Datensätzen, die sie beschreiben. Die Nachteile bestehen darin, dass die Schlüsselwortsuche bewusst konstruiert werden muss und das hybride Ranking direkt in SQL umgesetzt werden muss.

Fazit

Alle drei Systeme können Vektoren zuverlässig speichern und durchsuchen. In der getesteten Größenordnung waren ihre Antwortzeiten zudem weitgehend vergleichbar. Bedeutender sind die Unterschiede bei der Qualität der zurückgegebenen Ergebnisse und beim Umfang der Suchlogik, die von Anwendungsentwicklern selbst umgesetzt werden muss. Hybrides Retrieval erzielte insgesamt die stärkste Qualität. pgvector erforderte eine sorgfältige Konstruktion der Abfragen für eine wirksame Schlüsselwortsuche, OpenSearch benötigte eine gezielte Konfiguration von Analyzer und Recall, und Weaviate lieferte in diesem Vergleich die höchste Retrieval-Qualität bei gleichzeitig geringstem Bedarf an eigener Hybrid-Suchlogik.

Für Anwendungen, bei denen Suche lediglich eine Funktion neben relationalen Daten darstellt, kann pgvector einen zusätzlichen Dienst überflüssig machen und Vektoren nahe bei den Daten halten, die sie beschreiben. Gleichzeitig muss mehr Verhalten für Schlüsselwort- und Hybrid-Suche innerhalb der Anwendung selbst umgesetzt werden. Bei Anwendungen, in denen Suche eine zentrale Produktfunktion darstellt, führt die Implementierung hybrider Suche mit OpenSearch oder pgvector zu zusätzlichem Betriebsaufwand durch getrennte Retrieval-Pfade, eigene Fusion-Logik und konsistentes Tuning über verschiedene Clients hinweg. Weaviate ersetzt einen großen Teil dieser Implementierung durch eine einzelne hybride Abfrage und einen Gewichtungsparameter und erzielte dabei in diesem Vergleich die stärkste Retrieval-Qualität.