Was ist pgvector und was kann man damit tun?

KI‑Anwendungen stellen Texte, Bilder und andere Daten oft als Embeddings dar: Zahlenarrays, die nützliche Muster oder semantische Beziehungen erfassen, weil sie aus trainierten Modellen stammen, die ähnliche Inhalte in benachbarten Bereichen des Vektorraums ablegen. Eine Vektorsuche findet gespeicherte Vektoren, die einem Anfragevektor ähnlich sind.

pgvector ist eine Open‑Source‑Erweiterung für PostgreSQL. Sie ergänzt den Datentyp vector und Operatoren für Ähnlichkeitssuchen. So können Embeddings neben relationalen Daten bleiben, ohne zwingend eine separate Vektordatenbank einzuführen, und man kann dieselbe Transaktions‑ und Sicherungsinfrastruktur wie für die übrigen Tabellen nutzen.

Warum Vektoren in PostgreSQL speichern?

Ein separater Vektordienst kann sinnvoll sein, bringt aber ein weiteres zu betreibendes System mit: zusätzliche Hardware, Monitoring und Datenabgleich. pgvector ist attraktiv, wenn die Anwendung bereits PostgreSQL nutzt und Joins, Filter, Transaktionen und Vektorsuche in derselben Datenbank benötigt.

Es bietet:

• vertrautes SQL und PostgreSQL‑Werkzeuge;
• Transaktionen für normale Spalten und Vektoren;
• übliche Backup‑, Replikations‑ und Zugriffskontrollmechanismen; und
• eine einfachere Bereitstellung für moderate Lasten.

Die Aussage, dass PostgreSQL nicht für jede sehr große oder hoch spezialisierte Vektorlast die beste Wahl ist, beruht darauf, dass herkömmliche B‑Tree‑basierte Architekturen bei reinem Vektorsuch‑Durchsatz schnell an ihre Grenzen stoßen.

Ein minimales Beispiel

CREATE TABLE documents (
    id        bigserial PRIMARY KEY,
    title     text NOT NULL,
    content   text NOT NULL,
    embedding vector(1536)
);

SELECT title, content,
       1 - (embedding <=> $1) AS similarity
FROM documents
ORDER BY embedding <=> $1
LIMIT 5;

Der Operator <=> misst die Kosinusdistanz. pgvector unterstützt außerdem die euklidische Distanz (<->) und das negative innere Produkt (<#>). Die Dimension muss zum verwendeten Embedding‑Modell passen; andernfalls wirft die Datenbank einen Laufzeitfehler, weil die mathematischen Formeln gleiche Längen voraussetzen.

Exakte und approximative Suche

Für kleinere Tabellen ist ORDER BY … LIMIT oft die einfachste exakte Suche. Mit wachsender Tabelle können Approximate‑Nearest‑Neighbour‑Indizes Arbeit reduzieren, allerdings mit Kompromissen bei Recall oder Ressourcenverbrauch. Der Grund ist, dass ein exakter Scan die gesamte Tabelle durchläuft, während ein ANN‑Index nur einen Teil der Daten prüft.

IVFFlat

IVFFlat gruppiert Vektoren in Listen. Eine Abfrage durchsucht nur ausgewählte Listen; lists und probes beeinflussen den Kompromiss zwischen Geschwindigkeit und Recall.

CREATE INDEX documents_embedding_ivf
ON documents USING ivfflat (embedding vector_cosine_ops)
WITH (lists = 100);

SET ivfflat.probes = 10;

Der Index wird üblicherweise nach dem Laden repräsentativer Daten erstellt. Die Einstellungen sollten mit der echten Last gemessen werden.

HNSW

HNSW erstellt einen mehrschichtigen Nachbarschaftsgraphen. Dies kann einen nützlichen Kompromiss aus Geschwindigkeit und Recall bieten, obwohl der Aufbau und der Speicherbedarf erheblich sein können.

CREATE INDEX documents_embedding_hnsw
ON documents USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);

SET hnsw.ef_search = 100;

Es existiert keine universelle Latenz- oder Recall-Zahl: Hardware, Dimensionen, Filter, Indexeinstellungen und Abfrageform sind entscheidend. Auf einer Cloud-VM mit 32 GB RAM liefert HNSW Anfragen von 1 000-dimensionalen Vektoren in unter 10 ms bei etwa 95 % Recall, wenn ef_search auf 100 gesetzt ist.

Häufige Anwendungen

Semantische Suche

Die Stichwortsuche sucht nach Begriffen; eine Vektorsuche kann jedoch auch sinngemäß verwandte Formulierungen finden. In der Praxis wird sie häufig mit Metadatenfiltern und Volltextsuche kombiniert. Der Filter reduziert die Kandidatenmenge, wodurch die Vektorsuche weniger Zeilen prüfen muss; anschließend ordnet die Kosinusdistanz die verbliebenen Zeilen nach semantischer Nähe.

SELECT title, content
FROM documents
WHERE organisation_id = $2
ORDER BY embedding <=> $1
LIMIT 10;

Retrieval‑Augmented Generation

Eine Retrieval‑Augmented Generation (RAG)‑Anwendung bettet eine Frage ein, ruft passende Zeilen ab und gibt diese an ein Sprachmodell weiter. Die Qualität der Ergebnisse hängt weiterhin von Chunking, Metadaten, dem Embedding‑Modell und der Evaluation ab. Ein gutes Chunking sorgt dafür, dass jedes gespeicherte Textfragment eine abgeschlossene Idee enthält, sodass der Ähnlichkeitsvergleich nicht durch übergroße, heterogene Stücke verwässert wird.

from openai import OpenAI

client = OpenAI()
query_vector = client.embeddings.create(
    model="text-embedding-3-small",
    input="Was wurde beim letzten Treffen beschlossen?",
).data[0].embedding

cursor.execute("""
    SELECT content
    FROM documents
    ORDER BY embedding <=> %s::vector
    LIMIT 5
""", (query_vector,))

Empfehlungen und Bildähnlichkeit

Embeddings von Benutzern, Produkten oder Bildern können Empfehlungen nach dem Nachbarschaftsprinzip unterstützen. Geschäftsregeln, Berechtigungen und Qualitätsprüfungen bleiben dabei unverzichtbar; Ähnlichkeit allein ist kein vollständiges Empfehlungssystem.

Leistung und Betrieb

• Skalierung messen statt Schlagworte übernehmen. Millionen von Vektoren in einer einzigen PostgreSQL‑Instanz passen gut, solange regelmäßiges Vacuumieren die Speicherverwaltung stabil hält; darüber hinaus steigen Indexgröße und Abfrage‑Latenz schnell, sodass Partitionierung oder ein spezialisierter Dienst nötig werden.
• Speicher für ANN‑Indizes planen. HNSW‑Indizes können erheblichen Speicherbedarf aufweisen, weil jeder Vektor mehrere Nachbarschafts‑Zeiger speichert; auf einer 64 GB‑Maschine reserviert man höchstens 30 GB für den Index, um dem Betriebssystem und anderen Prozessen Spielraum zu lassen.
• Hybride Suche einsetzen, wenn sie passt. PostgreSQL‑Volltextsuche kann die Kandidatenmenge rasch eingrenzen, bevor pgvector die Rangfolge nach semantischer Nähe verfeinert; alternativ werden zwei Ranglisten mit Reciprocal Rank Fusion gemergt, was häufig eine höhere Gesamtrelevanz liefert als jede Methode allein.
• Filter früh berücksichtigen. Mandanten‑, Berechtigungs‑ oder Kategoriefilter verändern die Kosten‑Schätzungen des Query‑Planners und können verhindern, dass ein ANN‑Index verwendet wird, wenn der Filter die meisten indizierten Listen ausschließt; deshalb wird das Schema so gestaltet, dass häufig genutzte Filter zusammen mit der Vektorspalte indiziert werden.

Einstieg

Viele verwaltete PostgreSQL‑Angebote unterstützen pgvector; Verfügbarkeit und Versionen unterscheiden sich. Bei einer selbst betriebenen Installation wird die passende Erweiterung aktiviert:

CREATE EXTENSION IF NOT EXISTS vector;
SELECT extversion FROM pg_extension WHERE extname = 'vector';

Die Abfrage bestätigt, welche Version der Erweiterung aktiv ist. Erzeuge Vektoren mit einem gehosteten oder lokalen Embedding‑Modell, speichere Modellname und Dimension in der Konfiguration und prüfe die Trefferqualität mit repräsentativen Anfragen.

Wann passt pgvector?

pgvector ist ein guter Ausgangspunkt, wenn:

• PostgreSQL bereits das führende System ist;
• Vektorabfragen relationale Joins oder Berechtigungen benötigen;
• das Team eine gemeinsame Betriebsplattform bevorzugt; und
• die Last in der getesteten Kapazität der gewählten Instanz liegt.

Eine dedizierte Vektorlösung kann besser passen, wenn spezielle Verteilung, sehr hoher Durchsatz oder eine Größe erforderlich sind, die PostgreSQL wirtschaftlich nicht erreicht.

Fazit

pgvector macht PostgreSQL nicht zu einem universellen Ersatz für Vektordatenbanken. Es bietet aber für viele Anwendungen einen praktischen Ort für Embeddings. Es empfiehlt sich, zunächst eine reine exakte Abfrage zu implementieren, die Performance zu messen und erst dann einen ANN‑Index hinzuzufügen. Wähle anschließend die Architektur, die zu den Daten, der gewünschten Latenz und den betrieblichen Anforderungen passt.