pgvector: die vektorbasierte Suche in PostgreSQL

#Das Argument: keinen zusätzlichen Dienst hinzufügen

Eine lokale Installation für die Arbeit mit Dokumenten betreibt bereits einen Modellserver, einen Kodierungsschritt und einen Dokumentenspeicher. Eine dedizierte Vektordatenbank hinzuzufügen bedeutet einen zusätzlichen Container, einen zusätzlichen Port, eine zusätzliche Sicherung und eine weitere Komponente, die beim Löschen eines Dokuments nicht mehr mit Ihren relationalen Daten synchron sein kann.

Wenn PostgreSQL bereits vorhanden ist — und in einer Geschäftsanwendung ist das fast immer der Fall — beseitigt pgvector diese ganze Kategorie von Problemen. Ihre Textabschnitte liegen in einer Tabelle neben den Dokumenten, aus denen sie stammen, mit Fremdschlüsseln, die ihre Konsistenz gewährleisten. Löschungen werden so weitergegeben, wie Sie es erwarten, ohne dass Sie eine separate Bereinigungsaufgabe schreiben oder überwachen müssen. Das Projekt ergänzt außerdem exakte und approximative Suche, Vektoren mit einfacher und halber Genauigkeit sowie binäre und dünn besetzte Vektoren, fünf Distanzmaße (L2, Skalarprodukt, Kosinus, L1, Hamming, Jaccard) und übernimmt ohne Zusatzaufwand die ACID-Konformität, die Wiederherstellung zu einem bestimmten Zeitpunkt und die Joins von PostgreSQL.

#Wie es in der Praxis funktioniert

Sie speichern eine Spalte mit Vektoren neben Ihren üblichen Spalten. Eine Abfrage sortiert die Zeilen nach dem Abstand zum Vektor der Frage und gibt die nächstgelegenen zurück. Drei Abstandsoperatoren decken die gängigen Fälle ab, und der gewählte Operator muss zur Konvention des Embedding-Modells passen: Eine falsche Wahl ist die häufigste Ursache für mittelmäßige Ergebnisse, die nicht sofort auffallen. Bei auf Länge 1 normierten Vektoren (wie bei OpenAI und den meisten neueren Embedding-Modellen) lässt sich das Skalarprodukt am schnellsten berechnen und liefert dieselbe Rangfolge wie die Kosinusähnlichkeit.

#Minimaler SQL-Code zum Start

1. 01
   Erweiterung aktivieren

   CREATE EXTENSION IF NOT EXISTS vector; — ein einziger Befehl, der einmal pro Datenbank auszuführen ist.
2. 02
   Spalte hinzufügen

   ALTER TABLE chunks ADD COLUMN embedding vector(1024); — die Dimension muss exakt derjenigen des verwendeten Embedding-Modells entsprechen.
3. 03
   Daten vor dem Indexieren laden

   Ein Massenimport über COPY ist ohne bestehenden Index schneller; erstellen Sie den Index, sobald eine repräsentative Anzahl von Zeilen vorhanden ist.
4. 04
   Index erstellen

   CREATE INDEX CONCURRENTLY ON chunks USING hnsw (embedding vector_cosine_ops); — die Option CONCURRENTLY verhindert, dass Schreibvorgänge während der Indexerstellung blockiert werden, die bei einer großen Tabelle lange dauert.
5. 05
   Abfragen

   SELECT contenu FROM chunks WHERE document_id IN (SELECT id FROM documents WHERE utilisateur_autorise($1)) ORDER BY embedding <=> $2 LIMIT 5; — Berechtigungsfilter und Sortierung nach Ähnlichkeit in derselben Abfrage.

#Die Grenzen der Dimensionszahl in der Praxis

pgvector definiert vier Spaltentypen, jeder mit seiner eigenen Grenze für die indexierbare Dimension. Der Standardtyp vector (Einfachgenauigkeit, 4 Bytes pro Element) ist bis zu 2 000 Dimensionen indexierbar, was die meisten gängigen Open-Source-Embedding-Modelle abdeckt (384 bis 1 024 Dimensionen). Ein breiteres Modell wie text-embedding-3-large von OpenAI mit standardmäßig 3 072 Dimensionen überschreitet diese Grenze: Die dokumentierte Lösung besteht entweder darin, die Dimension bei der Erzeugung des Embeddings zu reduzieren (die API ermöglicht dies), oder auf den Typ halfvec umzusteigen, der in Halbgauigkeit speichert (2 Bytes pro Element, halb so viel Speicherplatz) und bis zu 4 000 Dimensionen indexierbar ist. Der Typ bit (binäre Vektoren, Hamming- oder Jaccard-Abstände) ist bis zu 64 000 Dimensionen indexierbar, und sparsevec (dünne Vektoren) bis zu 1 000 nicht-null-Elementen indexiert – darüber hinaus speichert PostgreSQL die Spalte weiterhin (bis zu 16 000 Dimensionen für vector, halfvec und sparsevec), kann sie aber nicht indexieren, was zu einem exakten Durchlauf führt.

#Das Filtern und die Zugriffsrechte

Eine reale Frage bezieht sich selten auf den gesamten Korpus: Gesucht sind die Passagen dieses Dienstes, die nach diesem Datum entstanden sind, in den Dokumenten, die dieser Benutzer lesen darf. In einer dedizierten Vektordatenbank ist das ein Metadatenfilter mit eigener Syntax und eigenen Sonderfällen. In PostgreSQL ist es eine WHERE-Klausel zusammen mit einer Sortierung nach Ähnlichkeit, bei Bedarf mit einer Verknüpfung zu Ihrer Benutzertabelle.

Eine vom Projekt selbst dokumentierte Stolperfalle sollten Sie kennen, bevor Sie im Produktivbetrieb darauf stoßen: Bei einem approximativen Index (HNSW oder IVFFlat) wird der Filter nach dem Indexdurchlauf angewendet, nicht davor. Wenn eine Bedingung nur 10 % der Zeilen durchlässt und der Parameter hnsw.ef_search den Standardwert 40 hat, werden im Durchschnitt nur 4 Zeilen zurückgegeben – nicht die zehn angeforderten. Die offizielle Abhilfe, die seit Version 0.8.0 verfügbar ist, heißt iterativer Indexdurchlauf (SET hnsw.iterative_scan = strict_order). Dabei wird der Durchlauf automatisch erneut gestartet, bis genügend Ergebnisse gefunden wurden, statt stillschweigend eine unvollständige Ergebnismenge zurückzugeben.

#Wo die Grenzen liegen

Speicherbedarf bei großen Datenmengen

Millionen Vektoren mit voller Präzision benötigen viel Speicher; halfvec und binäre Quantisierung reduzieren den Speicherbedarf, doch spezialisierte Engines bieten von Haus aus eine noch stärkere Komprimierung. Das ist der deutlichste Unterschied.

Dauer der Indexierung

Der Aufbau eines HNSW-Indexes auf einer sehr großen Tabelle dauert lange und benötigt viele Ressourcen; in der Produktion verhindert der Aufbau mit CREATE INDEX CONCURRENTLY, dass Schreibvorgänge währenddessen blockiert werden.

Konkurrierende Lasten

Wenn Sie aufwendige Vektorsuchen neben Ihrer Transaktionslast ausführen, laufen beide auf demselben Server. Lesereplikate helfen, eine Trennung der Rollen hilft noch mehr.

Die Dimension der Vektoren

Für indexierte Vektoren gilt je nach Typ eine Obergrenze (2.000 für vector, 4.000 für halfvec). Gängige Modelle passen innerhalb dieser Grenzen; ein Modell mit sehr hoher Dimension muss reduziert oder quantisiert werden.

Hybride Suche

PostgreSQL unterstützt Volltextsuche (tsvector), und Sie können sie mit der Vektordistanz kombinieren. Die komfortable Nutzung müssen Sie jedoch selbst umsetzen: Sie müssen die beiden Abfragen getrennt ausführen und anschließend die Ranglisten zusammenführen, beispielsweise mit Reciprocal Rank Fusion, statt mit einer einzigen Abfrage einen nativen hybriden Score zu erhalten.

Die horizontale Skalierung

Für den Betrieb auf mehr als einem Server führt der dokumentierte Weg über PostgreSQL-Lesereplikate oder ein Verteilungstool wie Citus oder PgDog – ein zusätzlicher Baustein, der dem ursprünglichen Argument entgegensteht.

#pgvector oder eine dedizierte Datenbank

Die Frage ist nicht, welche Lösung objektiv besser ist, sondern welche heute zu Ihrer Situation passt. pgvector hat die Nase vorn, sobald PostgreSQL bereits die maßgebliche Datenquelle der Anwendung ist: Abrechnung, Konten, Quelldokumente. Eine dedizierte Engine hat die Nase vorn, wenn die Menge der Vektoren oder der Abfragedurchsatz über das hinausgeht, was ein einzelner Transaktionsserver bewältigen kann, ohne den Rest der Anwendung zu beeinträchtigen, oder wenn das Team die KI-Komponente aus betrieblichen Gründen und nicht wegen der reinen Leistung vom übrigen Informationssystem trennen möchte.

• Qdrant: die spezialisierte Vektordatenbank
• Milvus, wenn das Datenvolumen die Leistungsgrenzen von pgvector überschreitet
• FAISS: Die Bibliothek hinter der Vektorsuche
• Die vollständige RAG-Kette aufbauen
• Ein Embedding-Modell auswählen
• Das lokale RAG-Kit QuelLLM: Alle Komponenten auf einer Seite
• Quelle: offizielles pgvector-Repository auf GitHub
• Quelle: Dokumentation zu den Indizes und Datentypen von pgvector
• Quelle: Leitfaden zur Skalierung von pgvector

#FAQ