Viele Unternehmen stehen aktuell vor der Frage, wie sich Large Language Models sinnvoll in bestehende IT-Landschaften integrieren lassen, ohne dafür eine vollständig neue Infrastruktur und damit einhergehendes Wissen aufzubauen. Ein zentrales technisches Element moderner KI-Anwendungen ist dabei die Vektorsuche. Sie ermöglicht es, Daten nicht nach exakten Übereinstimmungen, sondern nach semantischer Ähnlichkeit zu durchsuchen. Also nach Bedeutung statt nach Wortlaut.

Für viele Teams hört sich dies nach einem spezialisierten System an, das eingeführt, betrieben und gewartet werden muss. Dieser Beitrag zeigt, warum das in vielen Fällen nicht notwendig ist, und wie PostgreSQL mit der Extension pgvector zu einem vollwertigen Vektor-Store wird, ohne die bestehende Infrastruktur zu erweitern.

Klassisches SQL kennt keine Bedeutung

Relationale Datenbanken sind für präzise, strukturierte Abfragen konzipiert. Eine Suche mit WHERE inhalt LIKE '%Gewährleistung%' liefert ausschließlich Datensätze, in denen dieses Wort exakt so vorkommt. Steht im Datensatz stattdessen „Garantie” oder „24-monatiger Schutz”, gibt die Abfrage kein Ergebnis zurück, obwohl der Inhalt derselben Bedeutung entspricht.

Dies ist keine Schwäche von PostgreSQL, sondern die systembedingte Eigenschaft textueller Suche. SQL wurde für eindeutige, strukturierte Daten entwickelt. Bedeutung war kein Teil des relationalen Datenmodells.

In der Praxis führt das zu einem konkreten Problem: Nutzer:innen formulieren Suchanfragen in natürlicher Sprache. Dokumente, Tickets und Handbücher sind in natürlicher Sprache verfasst. Beide Seiten verwenden unterschiedliche Formulierungen für denselben Sachverhalt und die klassische Datenbanksuche kann diese Lücke nicht schließen.

Full-Text Search (FTS) in PostgreSQL verbessert die Situation durch Stemming und Stopwörter, bleibt aber im Kern auf lexikalische Ähnlichkeit beschränkt. „Meer” und „Küste” sind für Full-Text-Search zwei verschiedene Wörter ohne semantische Verbindung. Die Vektorsuche löst dieses Problem grundlegend: Sie sucht nicht nach Wörtern, sondern nach Bedeutung.

Was ist ein Vektor und wie entsteht er?

Ein Embedding-Modell, beispielsweise mxbai-embed-large von Ollama oder text-embedding-3-small von OpenAI, nimmt einen Text als Eingabe und gibt eine geordnete Liste von Dezimalzahlen zurück. Diese Liste wird als Vektor oder Embedding bezeichnet.

„Strandurlaub auf Bali” → [0.12, -0.87, 0.34, 0.61, ...] (1024 Werte)

„Urlaub am Meer” → [0.11, -0.85, 0.36, 0.59, ...] (1024 Werte)

„Skiurlaub in den Alpen” → [-0.44, 0.23, -0.71, 0.12, ...] (1024 Werte)

Die ersten beiden Vektoren ähneln sich stark: Sie zeigen in nahezu dieselbe Richtung im 1024-dimensionalen Raum. Der dritte Vektor unterscheidet sich deutlich. Semantische Ähnlichkeit wird damit zu geometrischer Nähe, die sich mathematisch berechnen lässt.

Das Embedding-Modell hat diese Bedeutungsrelationen aus großen Textmengen gelernt. Es hat erkannt, dass „Strand”, „Meer” und „Küste” in ähnlichen Kontexten vorkommen und bildet diese Erkenntnis in den Vektoren ab. Diese Repräsentation ist sprachunabhängig und robust gegenüber unterschiedlichen Formulierungen des selben Sachverhalts.

Die Anzahl der Dimensionen, also die Länge des Vektors, hängt vom gewählten Modell ab:

​Modell	​Dimensionen	​Betrieb
​mxbai-embed-large	​1024	​Lokal via Ollama
​nomic-embed-text	​768	​Lokal via Ollama
​text-embedding-3-small	​1536	​OpenAI API
​text-embedding-3-large	​3072	​OpenAI API

Mehr Dimensionen bedeuten in der Regel mehr Ausdrucksstärke bei feineren Bedeutungsunterschieden, jedoch auch höheren Speicherbedarf und langsamere Distanzberechnungen. Für die meisten Unternehmensanwendungen sind 768 bis 1024 Dimensionen ein guter Startpunkt. 

Was pgvector ist und was es leistet

pgvector ist eine Open-Source-Extension für PostgreSQL, entwickelt von Andrew Kane und auf GitHub aktiv gepflegt. Sie fügt drei zentrale Komponenten hinzu: einen neuen Datentyp, drei Distanzoperatoren und einen spezialisierten Index. Diese drei Komponenten bilden zusammen die vollständige technische Grundlage für semantische Suche innerhalb von PostgreSQL. 

1. Ein neuer Datentyp: vector(n)

Die Aktivierung und grundlegende Einrichtung ist mit wenigen SQL-Befehlen erledigt: 

vector(1024) speichert einen Vektor mit 1024 Dimensionen direkt als Tabellenspalte, gleichwertig zu INTEGER, TEXT oder TIMESTAMP. Es gibt kein separates System, keinen externen Store und keine Synchronisation zwischen zwei Datenquellen. Text und zugehöriger Vektor stehen in derselben Zeile, in derselben Transaktion, im selben Backup.

Intern speichert pgvector jeden Vektor als Array von 32-Bit-Gleitkommazahlen. Ein Vektor mit 1024 Dimensionen belegt damit etwa 4 KB Speicherplatz pro Datensatz. Bei einer Million Einträgen entspricht das rund 4 GB für die Vektorspalte, zuzüglich des Overheads für den Index.

2. Drei Distanzoperatoren

Die Vektorsuche basiert auf der Berechnung von Ähnlichkeit zwischen zwei Vektoren. pgvector stellt dafür drei Operatoren bereit, die jeweils eine andere mathematische Methode verwenden. Die Wahl des Operators hat direkte Auswirkungen auf die Qualität der Suchergebnisse und muss zum verwendeten Embedding-Modell passen.

​Operator	​Bezeichnung	​Methode	​Geeignet für
​<=>	​Cosine Distance	​Misst den Winkel zwischen Vektoren	​Text-Embeddings
​<->	​L2 Distance	​Euklidischer Abstand im Vektorraum	​Numerische, geometrische Daten
​<#>	​Inner Product	​Gewichtete Überlappung	​Normalisierte Vektoren

Cosine Distance: <=>

Die Cosine Distance ist der am häufigsten verwendete Operator für Text-Embeddings. Sie misst den Winkel zwischen zwei Vektoren im mehrdimensionalen Raum, unabhängig von deren Länge.

Der entscheidende Vorteil: Nur die Richtung der Vektoren zählt, nicht ihre Länge. Ein kurzer Satz und ein langer Absatz, die denselben Sachverhalt beschreiben, zeigen in nahezu dieselbe Richtung, auch wenn ihre Vektoren unterschiedlich lang sind. Je kleiner der Winkel zwischen zwei Vektoren, desto ähnlicher sind die zugrunde liegenden Texte. In der Praxis rechnet man das Ergebnis oft in einen lesbaren Ähnlichkeitsscore um, bei dem 1.0 identische Bedeutung und 0.0 keine Ähnlichkeit bedeutet:

Für die meisten RAG-Anwendungen mit Text-Embeddings ist Cosine Distance die richtige und sichere Wahl. Die meisten Embedding-Modelle sind explizit dafür optimiert, darunter lokale Modelle wie mxbai-embed-large von Ollama ebenso wie API-basierte Modelle wie text-embedding-3 von OpenAI. 

L2 Distance: <->​

Die L2 Distance, auch euklidische Distanz genannt, misst den direkten geometrischen Abstand zwischen zwei Punkten im Vektorraum. Dies entspricht dem direkten geometrischen Abstand zwischen zwei Punkten, angewandt auf mehrere hundert oder tausend Dimensionen statt auf zwei oder drei.

Im Gegensatz zur Cosine Distance spielt hier die Länge der Vektoren eine wichtige Rolle. Zwei Vektoren, die in dieselbe Richtung zeigen, aber unterschiedlich lang sind, haben eine hohe L2 Distance, obwohl sie semantisch ähnlich sein könnten. Für nicht normalisierte Text-Embeddings führt das zu suboptimalen Suchergebnissen.

L2 Distance ist sinnvoll, wenn der absolute Abstand zwischen Vektoren inhaltlich relevant ist, zum Beispiel bei numerischen Merkmalen wie Koordinaten, Messwerten oder Bildmerkmalen. 

Inner Product: <#>​

Das Inner Product, auch Skalarprodukt oder Dot Product genannt, misst die Übereinstimmung der Ausrichtung zweier Vektoren. Je mehr sie übereinstimmen, desto höher der Wert. Es ist rechnerisch etwas schneller als Cosine Distance, weil ein interner Normalisierungsschritt entfällt.

Allerdings liefert es nur dann korrekte Ähnlichkeitswerte, wenn beide Vektoren normalisiert sind, also alle dieselbe Länge haben. Einige Embedding-Modelle, darunter die von OpenAI, liefern ihre Vektoren bereits normalisiert. Die Normalisierung kann alternativ manuell vorgenommen werden.

Ein wichtiger technischer Hinweis: pgvector gibt intern das negative Inner Product zurück, damit ORDER BY konsistent mit den anderen Operatoren funktioniert. Bei der Ausgabe muss das berücksichtigt werden:

Inner Product eignet sich besonders dann, wenn das Embedding-Modell explizit normalisierte Vektoren liefert und maximale Abfragegeschwindigkeit gewünscht ist. OpenAIs Modelle tun dies standardmäßig. Für nicht normalisierte Vektoren liefert Inner Product keine verlässlichen Ähnlichkeitswerte, weshalb in diesen Fällen Cosine Distance vorzuziehen ist. 

Zusammenfassung: Welcher Operator für welchen Anwendungsfall?​

​Operator	​Methode	​Längenabhängig	​Empfohlen für
​<=>	​Cosine Distance​	​Nein	​Text-Embeddings (Standard)
<->​	​L2 Distance​	​Ja	​Numerische, geometrische Daten
​<#>	​Inner Product​	​Ja (entfällt bei Normalisierung)	​Normalisierte Vektoren, Hochlast

3. Der HNSW-Index​

Ohne Index muss PostgreSQL bei jeder Vektorsuche jeden einzelnen gespeicherten Vektor mit dem Query-Vektor vergleichen. Diese sogenannte exakte Suche, oder Brute-Force-Suche, ist vollständig korrekt, wird aber bei wachsenden Datenmengen schnell zum Engpass. Bei 100.000 Vektoren mit 1024 Dimensionen sind das pro Anfrage 100 Millionen Multiplikationen und Additionen.

pgvector implementiert den HNSW-Algorithmus (Hierarchical Navigable Small World) als primären Index. HNSW ist eine approximative Suchmethode: Sie findet mit sehr hoher Wahrscheinlichkeit die tatsächlich ähnlichsten Vektoren, garantiert dies aber nicht mathematisch. In der Praxis erreicht HNSW mit Standardparametern eine Recall-Rate von über 95 % bei deutlich kürzeren Antwortzeiten als Brute-Force.

Wie HNSW intern funktioniert​

HNSW baut beim Indexieren einen mehrstufigen Graphen auf, der von der Idee der „Small World Networks” inspiriert ist: In sozialen Netzwerken sind zwei beliebige Personen oft über nur wenige Zwischenstationen miteinander verbunden, obwohl das Netzwerk riesig ist.

Der Graph besteht aus mehreren Ebenen:

Oberste Ebene: Enthält nur wenige, weit voneinander entfernte Vektoren. Sie dient als grober Navigationslayer.

Mittlere Ebenen: Mit jeder niedrigeren Ebene werden mehr Vektoren aufgenommen und die Verbindungen dichter.

Unterste Ebene (Ebene 0): Enthält alle Vektoren, vollständig vernetzt mit ihren nächsten Nachbarn.

Eine Suche startet auf der obersten Ebene beim Eintrittspunkt, navigiert schrittweise zum jeweils ähnlichsten Knoten, wechselt in die nächste Ebene und wiederholt dies bis zur untersten Ebene. Dort wird in der dichten Nachbarschaft der beste Treffer identifiziert. Dieser Ansatz erreicht logarithmische Suchkomplexität: O(log n).

Der Parameter vector_cosine_ops legt fest, für welchen Distanzoperator der Index optimiert ist. Er muss zum Operator in der späteren Suchabfrage passen:

​Index-Parameter	​Passender Operator
​vector_cosine_ops​	​<=>​
​vector_l2_ops​	​<->​
​vector_ip_ops​	​<#>​

Die HNSW-Parameter m und ef_construction​

m (Standard: 16) definiert die Anzahl der bidirektionalen Verbindungen, die jeder Knoten im Graph maximal hat. Ein höherer Wert verbessert die Suchqualität, erhöht aber den Speicherbedarf des Index und verlangsamt den Aufbau.

Auf Ebene 0 hat jeder Knoten bis zu 2 * m Verbindungen, auf allen anderen Ebenen bis zu m. Als Faustregel gilt:

• m = 16: guter Ausgangspunkt für die meisten Anwendungsfälle
• m = 32: höhere Recall-Rate, etwa doppelter Index-Speicherbedarf
• m = 64: sehr hohe Qualität, empfohlen bei sehr ähnlichen Vektoren oder hohen Präzisionsanforderungen

ef_construction (Standard: 64) steuert die Suchtiefe beim Aufbau des Index. Konkret: Wie viele Kandidaten werden beim Einfügen eines neuen Knotens in den Graph evaluiert, um die besten Nachbarn zu finden? Ein höherer Wert produziert einen qualitativ besseren Graphen, verlängert aber den Indexierungsprozess erheblich.

Als Faustregel sollte ef_construction mindestens dem doppelten Wert von m entsprechen. Bei m = 16 ist ef_construction = 64 ein bewährter Startwert.

Vektorsuche in der Praxis

Eine vollständige semantische Suche mit pgvector kombiniert immer drei Elemente: den Distanzoperator für die Ähnlichkeitsberechnung, eine ORDER BY-Klausel für die Sortierung und optional WHERE-Filter für relationale Einschränkungen.

Der entscheidende Vorteil gegenüber spezialisierten Vektordatenbanken zeigt sich, sobald relationale Filter hinzukommen: 

Diese Query kombiniert semantische Ähnlichkeit mit Zugriffsrechten, Kategoriefilter und Zeitbeschränkung in einer einzigen SQL-Abfrage. In einer spezialisierten Vektordatenbank wäre diese Logik auf mehrere Systemgrenzen verteilt und müsste in der Anwendungsschicht koordiniert werden. 

Wann ist pgvector die richtige Wahl?

pgvector eignet sich für die meisten Unternehmensanwendungen, konkret dann, wenn:

• PostgreSQL bereits im Stack vorhanden ist
• Vektorsuche mit relationalen Daten kombiniert werden muss
• ACID-Transaktionen erforderlich sind
• die Datenmenge unter fünf bis zehn Millionen Vektoren liegt
• Betriebskomplexität und Kosten minimiert werden sollen

Spezialisierte Vektordatenbanken wie Qdrant oder Weaviate bieten Vorteile, wenn Datenmengen von zehn Millionen Vektoren deutlich überschritten werden, Vektorsuche der nahezu einzige Workload ist oder native Quantisierung zur RAM-Reduzierung zwingend benötigt wird.

Die Entscheidung sollte auf Basis messbarer Anforderungen getroffen werden, nicht auf Basis von Annahmen über zukünftige Skalierungsbedürfnisse. Der empfohlene Ansatz: mit pgvector starten, Performance und Recall-Rate unter realen Bedingungen messen und erst dann wechseln, wenn konkrete Grenzen nachweislich erreicht werden.

Fazit

​pgvector erweitert PostgreSQL um einen Datentyp, drei Distanzoperatoren mit unterschiedlichen mathematischen Eigenschaften und einen HNSW-Index für performante approximative Suche. Es macht damit aus einer relationalen Datenbank einen vollwertigen Vektor-Store, ohne zusätzliche Infrastruktur einführen zu müssen.

Die drei Operatoren <=>, <-> und <#> sind nicht austauschbar: Wer Text-Embeddings vergleicht, sollte <=> verwenden. Wer den Index anlegt, muss den passenden _ops-Parameter wählen. Und wer die Suchqualität optimieren möchte, hat mit den Index-Parametern m und ef_construction konkrete Stellschrauben zur Hand.

Im nächsten Teil dieser Serie wird gezeigt, wie pgvector in der Praxis eingesetzt wird: Texte einbetten, als Vektoren in PostgreSQL speichern, semantisch suchen und das Ergebnis als Kontext an ein lokales LLM übergeben. Das Ergebnis ist eine vollständige RAG-Pipeline mit kommentiertem Python-Code.

Sie möchten pgvector in Ihrem Unternehmen evaluieren oder eine RAG-Architektur auf Basis von PostgreSQL aufbauen? Sprechen Sie uns an! Wir helfen Ihnen, die richtige Lösung für Ihren konkreten Anwendungsfall zu entwickeln.

Seminarempfehlungen