Vektorfunktionen mit pgvector in PostgreSQL

Mit SQL Server 2025 führt Microsoft die Vektorunterstützung als native Engine-Funktion ein: einen integrierten Datentyp VECTOR(dim), spezielle Vektorfunktionen und einen in den Optimierer eng integrierten approximativen Vektorindex. Aus Sicht von SQL Server erscheint dies ganz natürlich – Vektoren werden zu einem weiteren Datentyp ersten Ranges, der über explizite Funktionen wie VECTOR_DISTANCE oder VECTOR_SEARCH abgefragt wird und durch eine spezielle Indexstruktur unterstützt wird.

In PostgreSQL wird dieselbe Funktion durch pgvector bereitgestellt – eine Erweiterung und keine Kernfunktion. pgvector ist jedoch kein einfaches Add-on. Es ist tief in den Planer und Executor von PostgreSQL integriert. Anstatt eine neue Abfragesyntax einzuführen, erweitert es bestehende SQL-Konzepte: Ausdrücke, Operatoren, Sortierung und Indizes.

pgvector versus SQL Server 2025

In SQL Server 2025 sind Vektoroperationen explizit und funktionsgesteuert. Die Entfernung wird durch Skalarfunktionen berechnet, und die ungefähre Suche nach dem nächsten Nachbarn wird durch eine spezielle Konstruktion initiiert. Der Abfragetext vermittelt klar die Absicht: Es handelt sich um eine Vektoroperation, die von der Engine speziell behandelt wird.

pgvector verfolgt einen anderen Ansatz. Es führt einen neuen Datentyp, vector(n), und eine Reihe von Operatoren ein, die die Entfernung zwischen Vektoren berechnen. Der wichtigste dieser Operatoren ist <->.

Der Operator <-> stellt die Entfernung zwischen zwei Vektoren dar. Konzeptionell erfüllt er dieselbe Rolle wie VECTOR_DISTANCE in SQL Server 2025, wird jedoch als Operator und nicht als Funktion ausgedrückt. Dieser Unterschied ist entscheidend:

• <-> gibt einen numerischen Wert zurück.
• PostgreSQL kann danach sortieren.
• PostgreSQL kann einen Index verwenden, um diese Sortierung durchzuführen.

Eine typische pgvector-Abfrage sieht daher wie folgt aus:

SELECT DocumentID, Title FROM Documents
 ORDER BY Embedding <-> '[0.2,0.4,0.6]'::VECTOR
 LIMIT 10;

Aus Sicht von SQL Server entspricht dies einer Sortierung nach einem berechneten Skalarausdruck und der Anwendung von TOP (10). Der Unterschied besteht darin, dass der Planer von PostgreSQL versteht, dass bestimmte Indizes (HNSW oder IVFFlat) diese Sortierung effizient erfüllen können. In SQL Server 2025 gibt es keine direkte Entsprechung zu <->, da SQL Server Entfernungen über Funktionen statt über Operatoren ausdrückt. Funktional lösen jedoch beide Systeme das gleiche Problem: Zeilen nach Ähnlichkeit sortieren und die obersten K zurückgeben.

HNSW in pgvector

Der am häufigsten verwendete Indextyp in pgvector ist HNSW, kurz für Hierarchical Navigable Small World Graph. Das Verständnis von HNSW ist für das Verständnis der Leistungsmerkmale von pgvector unerlässlich.

Die exakte Suche nach dem nächsten Nachbarn in einem hochdimensionalen Raum ist nicht skalierbar. Die Berechnung der Entfernung von einem Abfragevektor zu jeder Zeile entspricht einem vollständigen Tabellenscan mit einem hohen Rechenaufwand. HNSW existiert, um dieses Problem bei Hunderttausenden oder Millionen von Vektoren lösbar zu machen.

HNSW ist ein Algorithmus zur approximativen Suche nach dem nächsten Nachbarn (Approximate Nearest Neighbor, ANN). Er tauscht perfekte Genauigkeit gegen eine drastisch geringere Latenz und vorhersagbare Leistung ein, was genau den Anforderungen von Workloads wie semantischer Suche, Empfehlungssystemen und RAG-Pipelines entspricht. HNSW organisiert Vektoren in einem mehrschichtigen Graphen aus „Small World“-Netzwerken:

• Die oberen Schichten enthalten wenige Knoten mit langen Verbindungen. Sie ermöglichen lange „Sprünge“ über den Vektorraum hinweg.
• Die unteren Schichten sind dichter und bieten feinere Details und mehr Verbindungen zwischen näheren Nachbarn. Sie ermöglichen eine fein abgestufte lokale Navigation.
• Eine Abfrage beginnt in der obersten Schicht, durchläuft den Graphenund steigt dabei Schicht für Schicht ab, bis sie eine kleine Kandidatenmenge in der Nähe des Abfragevektors erreicht.

In pgvector wird HNSW als Indexzugriffsmethode bereitgestellt. Wenn wir einen HNSW-Index erstellen, teilen wir PostgreSQL mit: Diese Sortierung nach <-> kann mithilfe einer graphbasierten Struktur effizient approximiert werden.

CREATE INDEX documents_embedding_hnsw
 ON Documents
 USING hnsw (embedding vector_l2_ops);

Die Operatorklasse (vector_l2_ops) definiert, was <-> für diesen Index bedeutet – in diesem Fall die euklidische (L2-)Distanz.

Ein pgvector-Beispiel

Diese Anleitung spiegelt wider, wie ein SQL-Server-Experte jede neue Indizierungsfunktion bewerten würde: Festlegen einer Basislinie, Hinzufügen eines Index und Vergleichen von Ausführungsplänen. Aktivieren wir zunächst die Erweiterung:

CREATE EXTENSION IF NOT EXISTS vector;

Dadurch werden der Typ vector(n) und die Abstandsoperatoren, einschließlich <->, registriert.

Im nächsten Schritt verwenden wir eine einfache Multi-Tenant-Tabelle, da gefilterte Nearest-Neighbor-Abfragen Bereiche sind, in denen das ANN-Verhalten wirklich wichtig ist. Wir fügen auch einige Testdaten ein.

-- Erstellen einer einfachen Dokumententabelle.
 CREATE TABLE documents
 (
     DocumentID BIGSERIAL PRIMARY KEY,
     TenantID INT NOT NULL,
     Title TEXT NOT NULL,
     Embedding VECTOR(3) NOT NULL
 );
 
 -- Einige Daten einfügen
 INSERT INTO Documents (TenantID, Title, Embedding)
 SELECT
     (gs % 100) + 1,
     format('doc-%s', gs),
     ARRAY[
         random()::real,
         random()::real,
         random()::real
     ]::vector(3)
 FROM generate_series(1, 200000) AS gs;
 
 -- Aktualisieren der Statistiken
 ANALYZE Documents;

Ohne einen Vektorindex muss PostgreSQL die gesamte Tabelle scannen und die Abstände für jede Zeile berechnen.

-- Eine einfache Abfrage
 EXPLAIN (ANALYZE)
 SELECT DocumentID, Title FROM Documents
 ORDER BY Embedding <-> ‚[0.2,0.4,0.6]‘::VECTOR
 LIMIT 10;

Für einen SQL-Server-DBA sollte dies wie ein klassischer „Berechnen und Sortieren“-Plan aussehen – genau das, was man ohne einen unterstützenden Index erwarten würde.Auf meinem System läuft diese Abfrage etwa 30 ms lang (Bild 1).

Erstellen wir nun einen unterstützenden HNSW-Index für diese Abfrage:

-- Erstellen eines unterstützenden Index
 CREATE INDEX documents_embedding_hnsw
 ON Documents
 USING hnsw (embedding vector_l2_ops);

Führen wir nun dieselbe Abfrage erneut aus, wird in der Regel ein indexgesteuerter Plan mit deutlich geringerer Ausführungszeit und weniger E/A angezeigt (Bild 2).

Wie zu sehen ist, läuft die Abfrage jetzt nur noch etwa 1 ms, was eine signifikante Verbesserung darstellt.

Fazit

SQL Server 2025 und PostgreSQL mit pgvector gehen die Vektorsuche aus unterschiedlichen Blickwinkeln an. SQL Server legt den Schwerpunkt auf native Typen und explizite Vektorfunktionen. PostgreSQL legt den Schwerpunkt auf Kombinierbarkeit: Vektoren werden zu sortierbaren Werten, <-> wird zu einem erstklassigen Ordnungsoperator und HNSW wird zu einer weiteren Indexzugriffsmethode, die der Planer berücksichtigen kann.Für einen SQL-Server-DBA oder -Entwickler ist pgvector am besten nicht als fremdes Konzept zu verstehen, sondern als Erweiterung des relationalen Modells von PostgreSQL in einen hochdimensionalen Raum. Ausführungspläne sind nach wie vor wichtig. Statistiken sind nach wie vor wichtig. Filter sind nach wie vor wichtig. Die Werkzeuge sind unterschiedlich, aber die Disziplin ist dieselbe.