pgvector: Vektor-Suche im bestehenden PostgreSQL mit HNSW und IVFFlat

Was ist pgvector?

pgvector ist eine Erweiterung für PostgreSQL, die Vektor-Datentypen, Distanz-Funktionen und Vektor-Indizes hinzufügt. Sie wurde 2021 von Andrew Kane gestartet, steht unter der PostgreSQL-Lizenz (kompatibel zu MIT/BSD) und ist Mai 2026 in Version 0.8+ verfügbar. Anders als Qdrant, Weaviate oder Milvus ist pgvector kein eigenständiges System – es lebt in einer Postgres-Instanz, die ohnehin läuft.

Die Extension stellt drei Vektor-Datentypen bereit: vector(n) für Float32-Embeddings, halfvec(n) für Float16 (halber RAM-Footprint), bit(n) für binäre Vektoren (Binary-Quantization). Distanz-Funktionen kommen als Operatoren: <-> (L2/Euclidean), <#> (negative Dot Product), <=> (Cosine), <+> (L1/Manhattan, seit v0.7). Damit sind Anfragen wie SELECT * FROM docs ORDER BY embedding <=> $1 LIMIT 10 möglich – Vektor-Suche im gewohnten SQL-Idiom.

Vektor-Indizes existieren seit Version 0.5 in zwei Varianten: IVFFlat (Inverted File mit linearer Suche pro Liste, schnell zu bauen, gut bei moderater Genauigkeit) und HNSW (Hierarchical Navigable Small World, langsamer zu bauen, besserer Recall bei gleicher Latenz). Mit v0.8 (April 2026) sind binary-quantization-Indizes hinzugekommen – für Datasets, bei denen Speicherplatz das Engpass ist.

Die Killer-Eigenschaft ist die ACID-Konformität. Eine Transaktion kann gleichzeitig in einer Vektor-Tabelle und in einer klassischen relationalen Tabelle schreiben. Joins zwischen Vektor-Treffer und Stammdaten laufen in derselben Anfrage. Backup, Replication, Hochverfügbarkeit, RBAC, Audit-Logging – alles erbt pgvector von Postgres. Wer Postgres betreibt, betreibt pgvector ohne zusätzlichen Service.

Für CH-Treuhand- und KMU-Setups ist pgvector häufig die richtige Wahl, sobald Postgres bereits im Stack ist. Die Migration zu einer dedizierten Vektor-DB bleibt offen, falls Skalierung das verlangt – aber 80% der Treuhand-Fälle bleiben unter 5 Mio. Vektoren, und dort liefert pgvector Performance und Komfort, die kein Konkurrent übertrifft.

Warum es wichtig ist

Die meisten CH-Treuhand- und KMU-Stacks haben Postgres ohnehin laufen. Mandantenverwaltung, Belegerfassung, Lohnbuchhaltung – alles in Postgres. Eine zweite Datenbank für Vektor-Suche bedeutet: ein zweites Backup, ein zweites Monitoring, ein zweites Update-Fenster, ein zweites Failover-Konzept. Für kleine Teams ist das nicht zu unterschätzen – Komplexität hat Betriebskosten.

pgvector vermeidet diese Verdoppelung. Drei Konsequenzen folgen daraus. Erstens: operative Einfachheit. Backup läuft mit pg_dump, Replication mit Streaming-Replikation, Failover mit Patroni oder pgPool – alles bestehende Werkzeuge. Audit-Trail unter Art. 957a OR existiert in vielen Postgres-Setups bereits; Vektor-Inhalte fallen unter dieselbe Audit-Logik wie der Rest.

Zweitens: Joins. Eine relevante Anfrage in einer Treuhand-Plattform lautet selten „finde die 10 ähnlichsten Vektoren" pur. Sie lautet „finde die 10 ähnlichsten Vektoren unter den Belegen von Mandant 42, gib mir den Mandantennamen, das Belegdatum und den Buchungstext zurück". In pgvector ist das eine SQL-Anfrage mit JOIN; in Qdrant braucht es zwei Roundtrips (Vektor-Suche -> doc_ids -> Lookup in Postgres). Ein Roundtrip weniger spart Code und Fehlerquellen.

Drittens: Konsistenz. In einer Transaktion kann sowohl der Beleg-Eintrag als auch sein Embedding geschrieben werden. Schlägt eines fehl, rollt beides zurück. In einer Two-DB-Architektur (Postgres + Qdrant) muss diese Konsistenz manuell über Outbox-Pattern oder eventual consistency garantiert werden – Aufwand, der bei pgvector entfällt.

Die Schwäche von pgvector zeigt sich bei sehr grossen Datenmengen. Ab 10-20 Mio. Vektoren wird HNSW-Aufbau langsam und Such-Latenz steigt. Qdrant, Weaviate oder Milvus skalieren dort spürbar besser. Aber: 90% der CH-KMU-RAG-Pipelines bleiben unter 5 Mio. Vektoren – innerhalb dieses Bereichs ist pgvector die pragmatische Wahl.

Wie es funktioniert

Installation: pgvector kommt als Extension. Auf Ubuntu/Debian via apt install postgresql-16-pgvector; in Docker als pgvector/pgvector:pg16-Image; in Managed-Postgres bei Hetzner, DigitalOcean, AWS RDS, Azure Database oft als optionales Modul aktivierbar. Aktivierung pro Datenbank: CREATE EXTENSION vector;

Tabelle anlegen: CREATE TABLE docs (id bigserial PRIMARY KEY, mandant_id int, datum date, content text, embedding vector(1536));

Index anlegen – pflicht ab einigen Tausend Einträgen: CREATE INDEX docs_embed_hnsw ON docs USING hnsw (embedding vector_cosine_ops) WITH (m = 16, ef_construction = 64);

Die Parameter m und ef_construction steuern Qualität vs Build-Zeit. Default-Werte reichen bis ca. 1 Mio. Einträge; darüber lohnt m=32 und ef_construction=200.

Insert via klassisches SQL: INSERT INTO docs (mandant_id, datum, content, embedding) VALUES (42, 2026-04-01, Rechnung Müller, [0.123, -0.45, ...]);

In Python typisch mit psycopg2 oder asyncpg; pgvector-Python-Paket liefert sauberes Encoding.

Suche mit Filter: SELECT id, content, embedding <=> $1 AS distance FROM docs WHERE mandant_id = 42 AND datum > 2026-01-01 ORDER BY embedding <=> $1 LIMIT 10;

Der HNSW-Index wird vom Query-Planner automatisch genutzt, wenn ORDER BY embedding <=> ... LIMIT N steht. Filter über WHERE laufen vor oder nach der ANN-Suche, abhängig von Selektivität und Statistiken – pgvector v0.8 hat hier deutlich verbesserte Heuristiken gegenüber v0.7.

Hybrid-Suche mit Volltext: pgvector kann mit Postgres-eigenem tsvector kombiniert werden. Eine Anfrage kann BM25-Äquivalent über ts_rank und Vektor-Distanz in einem Score gemischt werden – kein separates Hybrid-Engine nötig, aber das Tuning des Mix-Gewichts ist manuell.

Backup: pg_dump deckt Schema, Daten und HNSW-Index ab. Recovery über pg_restore oder Point-in-Time-Recovery via WAL-Archiv. Streaming-Replikation läuft ohne Anpassung – Replica-Server haben automatisch denselben Vektor-Index.

pgvector in 5 Schritten produktiv

1. 01Extension installieren: bei Self-Hosted via apt oder Docker-Image pgvector/pgvector:pg16; bei Managed-Postgres im Provider-UI aktivieren. CREATE EXTENSION vector im Ziel-Schema.
2. 02Tabelle planen: embedding vector(N), zusätzliche Filter-Spalten (mandant_id, datum, vertraulichkeit) als klassische Postgres-Spalten. B-Tree-Indizes auf Filter-Spalten.
3. 03HNSW-Index anlegen: USING hnsw (embedding vector_cosine_ops) WITH (m=16, ef_construction=64). Default reicht für < 1 Mio.; ab 5 Mio. m=32 und ef_construction=200.
4. 04Insert in Batches via COPY oder Multi-Row-INSERT; bei grossen Bulk-Loads (> 1 Mio.) den HNSW-Index erst nach dem Load anlegen – sonst dauert es 3-5x länger.
5. 05Backup-Strategie wie für Postgres üblich: pg_dump täglich, WAL-Archivierung für Point-in-Time-Recovery, optional Streaming-Replica für Read-Skalierung.

Wann pgvector einsetzen

pgvector ist die richtige Wahl, wenn (a) Postgres bereits im Stack läuft, (b) die Datenmenge unter 10 Mio. Vektoren bleibt, (c) Joins zwischen Vektor-Treffer und Stammdaten häufig sind oder (d) ACID-Konsistenz zwischen Vektor-Schreib und relationalem Schreib erforderlich ist.

Konkrete Fälle: eine Treuhand-Plattform mit Bexio- oder Abacus-Anbindung speichert ohnehin Belege und Mandanten in Postgres. Eine RAG-Pipeline über dieselben Belege bekommt eine zusätzliche embedding-Spalte, einen HNSW-Index – keine zweite DB nötig. Eine juristische Fall-Management-App, die Präzedenzfälle semantisch sucht und mit Mandanten-Akten joint. Eine interne Suche über Mitarbeiter-Wissensbasis mit Berechtigungen über Postgres-Rollen.

pgvector eignet sich auch für Multi-Tenant-Setups bis ca. 100 Mandanten, mit client_id als Filter-Spalte und passendem B-Tree-Index. Pro-Mandant-Schema oder pro-Mandant-Datenbank ist über Postgres-Schemata sauber abbildbar; ein pg_dump pro Schema sichert ein Mandant.

Für Pilot-Projekte ohne Postgres-Erfahrung ist pgvector ebenfalls einstiegsfreundlich, weil SQL als Abfragesprache bekannt ist. Wer pgvector einrichtet, lernt zugleich Postgres – eine Fähigkeit mit langer Halbwertszeit.

Managed-Postgres-Provider wie Hetzner Postgres-Cloud, Aiven, Crunchy Bridge, Neon, Supabase und Timescale bieten pgvector als Standard-Modul. Für CH-strikte Hosting-Anforderungen ist Self-Hosted auf Hetzner Helsinki/Falkenstein oder Infomaniak die Wahl; alle anderen Provider erfordern eine TIA-Bewertung.

Wann NICHT

Ab ca. 20 Mio. Vektoren wird pgvector spürbar langsamer als dedizierte Vektor-DBs. HNSW-Aufbau auf 50 Mio. Vektoren dauert Stunden; Suche bleibt zwar unter 100 ms, ist aber 2-5x langsamer als Qdrant oder Milvus bei vergleichbarem Recall. Wer dauerhaft Volumen über 20 Mio. erwartet, fokussiert auf eine dedizierte Vektor-DB.

Für sehr hohe Such-QPS (> 500/Sekunde) ist pgvector ebenfalls suboptimal. Postgres ist auf Mixed-Workload optimiert; bei reiner Such-Last skalieren dedizierte Vektor-DBs über Read-Replicas oder Shards effizienter. Workaround in pgvector: Streaming-Read-Replicas, was bis ca. 5-10x QPS-Gewinn bringt.

Wenn Postgres nicht bereits läuft und kein anderer SQL-Use-Case existiert, ist die Installation eines kompletten Postgres-Servers nur für Vektor-Suche aufwendiger als eine Qdrant-Instanz. Qdrant ist ein Single-Binary; Postgres bringt Konfiguration, Tuning, Wartung mit. Wer ohne SQL-Wissen startet, hat mit Qdrant den schnelleren Weg.

Für Multi-Modal-Use-Cases (Text plus Bild im gleichen Vektor-Raum) ist Weaviate die ausgereiftere Wahl. pgvector kann Bild-Embeddings speichern, aber die Modul-Integration und das Schema-Tooling von Weaviate ist hier vorne.

Für Real-Time-Empfehlung mit Sub-10ms-Latenz unter sehr hoher Last ist Redis mit RediSearch oft schneller. pgvector liefert in den meisten Fällen 10-30 ms, was für RAG-Pipelines ausreichend, für Live-Feed-Personalisierung aber knapp ist.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. pgvector – GitHub repository, docs, and v0.8 release notes · 2026-05
2. PostgreSQL documentation – extensions and CREATE INDEX · 2026-05
3. Supabase blog – pgvector benchmarks and HNSW tuning · 2026-04
4. Crunchy Data – pgvector at scale, binary quantisation · 2026-05
5. ANN-Benchmarks – pgvector performance comparison · 2026-03