pgvector

Kurzfazit

pgvector ist die pragmatischste Antwort auf die Vektordatenbank-Frage — eine quelloffene PostgreSQL-Erweiterung von Andrew Kane, die Embedding-Speicherung, Ähnlichkeitssuche und Indizierung direkt in bestehender Postgres-Infrastruktur abbildet. Statt eine zweite spezialisierte Datenbank wie Pinecone oder Weaviate zu betreiben, fügst du CREATE EXTENSION vector; in deine vorhandene Postgres-Instanz ein und arbeitest mit demselben Werkzeugkasten — denselben Backups, derselben Replikation, denselben Berechtigungen, denselben Joins. Für die überwältigende Mehrheit kleiner und mittlerer RAG-Anwendungen, semantischer Suche und Empfehlungssysteme reicht pgvector vollständig aus und spart erheblichen Betriebsaufwand. Wer hunderte Millionen Vektoren mit harten Latenz-SLAs verwaltet, stößt an Grenzen — für alle anderen ist pgvector die rationale Erstwahl. Lizenz: MIT, Kosten für die Erweiterung: null.

Für wen ist pgvector?

Postgres-Shops mit RAG-Bedarf: Wenn dein Stack bereits PostgreSQL verwendet — sei es als Hauptdatenbank oder Analytics-Store — gibt es selten einen guten Grund, für Embeddings eine dedizierte Vektordatenbank einzuführen. pgvector eliminiert die zweite Datenbank, den zweiten Backup-Pfad und die zweite Berechtigungsmatrix. Eine Codezeile (CREATE EXTENSION vector) und du bist startklar.

Startups und Mittelstand mit kleinen bis mittleren Vektor-Mengen: Bis in den niedrigen Millionen-Bereich an Vektoren liefert pgvector mit HNSW-Index Sub-100-Millisekunden-Antwortzeiten — auf einer einzigen Postgres-Instanz, die ohnehin läuft. Das ist für die meisten Use-Cases (Produktkatalog-Suche, Wissensdatenbank, Support-Tickets) absolut ausreichend.

Entwicklerteams ohne dedizierte Infrastruktur-Kapazität: Eine eigene Vektordatenbank zu betreiben heißt: zweites Monitoring, zweite Disaster-Recovery, zweites Patching. Wer ein kleines Team hat, fährt mit „eine Datenbank, mehrere Aufgaben” deutlich besser. pgvector ist die offensichtliche Wahl für Lean-Setups.

Anwendungen mit gemischter Vektor- und Relationen-Logik: Sobald du Vektoren mit Berechtigungen, User-Metadaten oder transaktionalen Status-Feldern joinen musst, spielt pgvector seine Stärke aus: ACID-Transaktionen und ein voller SQL-Join-Optimizer in einer Anfrage. Bei externer Vektordatenbank musst du diese Logik in der Anwendung nachbauen — fehleranfällig und langsam.

Supabase-, Neon- und Cloud-Postgres-Nutzer: Auf Supabase ist pgvector standardmäßig aktivierbar (1-Klick), auf Neon, AWS RDS, Azure Database for PostgreSQL, Google Cloud SQL und Crunchy Bridge ebenfalls verfügbar. Wer bereits einen Managed-Postgres-Dienst nutzt, hat pgvector ohne zusätzliche Verträge oder Anbieter zur Hand.

Weniger geeignet für: Anwendungen mit hunderten Millionen oder Milliarden Vektoren und harten Latenz-SLAs (dort sind Pinecone oder Milvus besser), Teams ohne jegliche Postgres-Erfahrung (Tuning verlangt SQL- und Index-Know-how), reine SaaS-Anwender ohne Datenbank-Verwaltungswillen, und Anwendungen, die ausgereifte Hybrid-Suche (Volltextsuche + Vektor + Filter) als integriertes Feature brauchen.

Preise im Detail

Komponente	Preis	Was du bekommst
pgvector-Erweiterung	0 € (MIT-Lizenz)	Vollständige Vektor-Funktionalität, alle Distanz-Metriken, HNSW- und IVFFlat-Indizes
Selbst gehostete PostgreSQL	0 € (Lizenz) + Hosting-Kosten	Volle Kontrolle, beliebige Hardware oder Cloud-VM, ab ca. 5 €/Monat für eine kleine Hetzner-VM
Supabase Free	0 USD	500 MB Datenbank, pgvector vorinstalliert, ideal für Prototypen und kleine Anwendungen
Supabase Pro	25 USD/Monat	8 GB Datenbank, Auto-Pause, mehr Compute, AVV
Neon Free	0 USD	512 MB Storage, pgvector verfügbar, Branching-Funktion
Neon Launch	19 USD/Monat	10 GB, Autoscaling, mehr Compute
AWS RDS Postgres	ab 13 USD/Monat	db.t4g.micro mit pgvector, EU-Region (Frankfurt) verfügbar
Azure Database for PostgreSQL	ab ca. 25 USD/Monat	Burstable B1ms mit pgvector, EU-Regionen verfügbar
Google Cloud SQL	ab ca. 10 USD/Monat	db-f1-micro mit pgvector, europäische Regionen verfügbar

Einordnung: Die Erweiterung selbst kostet nichts — die einzigen Kosten sind die deiner Postgres-Instanz, die in vielen Stacks ohnehin schon läuft. Damit ist pgvector im Vergleich zu Pinecone (ab 70 USD/Monat für den Standard-Plan) oder Weaviate Cloud (ab 25 USD/Monat) ein erheblicher Sparhebel — vor allem, weil keine separate Infrastruktur entsteht. Für DSGVO-Anwender besonders wertvoll: Mit AWS RDS in Frankfurt, Azure in Deutschland-West-Central oder Hetzner in Nürnberg/Falkenstein lässt sich Vektor-Speicher vollständig in der EU betreiben — ohne zusätzliche Anbieterprüfung. Die wahre Kostenfrage ist nicht „pgvector vs. Pinecone”, sondern „eine Datenbank betreiben oder zwei”. pgvector entscheidet diese Frage in den meisten Fällen klar.

Stärken im Detail

Eine Datenbank, nicht zwei. Das ist die zentrale Stärke. Eine zusätzliche spezialisierte Vektordatenbank im Stack zu betreiben bedeutet: zweites Monitoring, zweite Backup-Pipeline, zweite Disaster-Recovery, zweite Berechtigungsmatrix, zweite Patching-Strategie, zweite Metrik-Dashboards. pgvector eliminiert all das. Die Erweiterung läuft als ganz normale Postgres-Komponente — alle vorhandenen DBA-Verfahren greifen unverändert.

ACID-Transaktionen und Joins. Vektoren sind selten alleinstehend nützlich. In der Realität willst du WHERE user_id = ? AND tenant = ? ORDER BY embedding <=> ? LIMIT 10 — also Vektor-Suche mit relationalen Filtern und Berechtigungen. pgvector erlaubt das in einer SQL-Anfrage, ACID-konsistent, mit dem vollen Postgres-Optimizer. Externe Vektordatenbanken bauen das mit Workarounds nach (Metadaten-Filter, Pre/Post-Filter) — selten so robust und nie so flexibel.

Drei Index-Typen, klare Trade-offs. pgvector unterstützt HNSW (Hierarchical Navigable Small World — höhere Recall, langsamer Build, mehr Speicher) und IVFFlat (Inverted File Flat — schnellerer Build, weniger Speicher, etwas geringere Recall). Du wählst je nach Workload: Read-lastig mit selten ändernden Vektoren → HNSW; Write-lastig mit häufigen Updates → IVFFlat oder gar kein Index (Brute-Force ist bei kleinen Mengen oft schnell genug).

Mehrere Vektor-Typen für Speicher-Tuning. Neben dem Standard-vector-Typ (32-Bit Float) gibt es halfvec (16-Bit, halber Speicher), bit (binäre Vektoren für Hamming-Distanz) und sparsevec (für seltene Vektoren wie SPLADE). Bei großen Embedding-Mengen lassen sich damit Speicher und Cache-Nutzung erheblich optimieren — eine Flexibilität, die viele dedizierte Vektordatenbanken nicht in dieser Form bieten.

Auf jedem Managed-Postgres-Dienst verfügbar. AWS RDS, Aurora, Azure Database for PostgreSQL, Google Cloud SQL, Supabase, Neon, Crunchy Bridge, DigitalOcean Managed Databases — pgvector ist überall standardmäßig aktivierbar. Das gibt strategische Flexibilität: Du kannst zwischen Anbietern wechseln, ohne Vektor-Daten zu migrieren, und du musst keinen einzelnen Vektor-DB-Anbieter evaluieren oder Preise verhandeln.

Aktive Entwicklung und breite Toolchain-Integration. Andrew Kane (auch Autor vieler weit verbreiteter Ruby-Gems wie searchkick, ahoy) pflegt das Projekt seit 2021 aktiv. LangChain, LlamaIndex, Supabase Vector, der OpenAI Cookbook und Dutzende weitere Tools haben pgvector als First-Class-Backend integriert. Ein Tutorial oder Code-Beispiel zu jedem typischen Use-Case ist eine Suchmaschinen-Anfrage entfernt.

Bewährte Backup- und Hochverfügbarkeitsverfahren. PostgreSQL-Backups, Streaming-Replikation, Point-in-Time-Recovery, Failover — das alles ist seit Jahrzehnten erprobt und gut verstanden. Vektordaten profitieren ohne zusätzlichen Aufwand davon. Externe Vektordatenbanken haben oft jüngere, weniger robuste Backup-Geschichten — ein realer operativer Risikoschnitt zugunsten von pgvector.

Schwächen ehrlich betrachtet

Skaliert nicht bis in den Milliarden-Bereich. Pgvector ist auf einer einzelnen Postgres-Instanz solide bis in den niedrigen Millionen-Bereich an Vektoren — danach werden Index-Builds langsam, RAM-Anforderungen explodieren und Anfragen werden träge. Wer ernsthaft mit hunderten Millionen oder Milliarden Vektoren arbeitet (Bildsuche im großen Stil, multi-tenant SaaS mit Massendaten), braucht spezialisierte Lösungen wie Milvus, Pinecone oder verteiltes Qdrant. Faustregel: Bei Suchen über mehr als 10 bis 50 Millionen Vektoren und Latenz-SLAs unter 50 ms wird die Architektur-Entscheidung neu zu prüfen.

HNSW-Index-Build ist speicherintensiv. Beim Erstellen eines HNSW-Index hält pgvector große Teile der Vektoren im Arbeitsspeicher — maintenance_work_mem muss großzügig dimensioniert sein, sonst wird der Build extrem langsam oder bricht ab. Bei mehreren Millionen 1.536-dimensionalen OpenAI-Embeddings sind das schnell mehrere Gigabyte. Auf kleineren Managed-Instanzen wird das zur echten Hürde.

HNSW unterstützt nur bis 2.000 Dimensionen. Größere Embeddings (z. B. 3.072-dimensionale text-embedding-3-large von OpenAI) lassen sich speichern, aber nicht mit HNSW indexieren. Workaround: Dimensionen reduzieren (Matryoshka-Representation-Learning unterstützt das nativ bei OpenAI-Modellen) oder ohne Index arbeiten (Brute-Force, nur bei kleinen Mengen praktikabel). Diese Begrenzung ist nicht trivial und betrifft viele aktuelle Embedding-Modelle.

Filterung mit Vektor-Suche ist tückisch. Eine Anfrage wie „finde die zehn ähnlichsten Dokumente, aber nur aus Kategorie X” klingt einfach, ist aber im Vektor-Indexing notorisch knifflig. Pgvectors HNSW kann „post-filter” liefern (erst Vektor-Suche, dann Filter — was zu wenigen oder gar keinen Treffern führen kann) oder den Index für gefilterte Suchen umgehen (langsamer). Es gibt Strategien (Partial-Indexes, gezielte Re-Ranking), aber sie verlangen Erfahrung. Dedizierte Vektordatenbanken wie Weaviate oder Qdrant haben hier ausgereiftere Lösungen.

Kein eingebautes Embedding-Modell. pgvector speichert Vektoren — aber generiert sie nicht. Du musst Embeddings extern erzeugen (OpenAI, Cohere, Hugging Face, lokale Modelle via Ollama) und beim Insert mitschicken. Tools wie Supabase Vector legen ein Wrapper-Layer darüber, das Embeddings inline erzeugt — aber pgvector selbst ist „nur” der Speicher.

Tuning verlangt Postgres-Erfahrung. work_mem, maintenance_work_mem, hnsw.ef_search, hnsw.iterative_scan, Index-Parameter m und ef_construction — das alles will verstanden und justiert sein, sobald die Anwendung produktiv läuft. Anders als ein verwalteter Vektor-Service ist pgvector kein „set and forget” — Performance hängt direkt an Postgres-Konfiguration.

Kein eingebautes Hybrid-Suche-Feature. Volltextsuche und Vektor-Suche kombiniert (Reciprocal Rank Fusion, Re-Ranking) ist ein Pattern, das in spezialisierten Vektordatenbanken zunehmend out-of-the-box angeboten wird. Mit pgvector baust du das selbst — Postgres hat zwar Volltextsuche (tsvector), aber die Kombination mit Vektor-Suche ist Eigenarbeit.

Alternativen im Vergleich

Wenn du…	…nimm stattdessen
Verwalteten Vektor-Service ohne Datenbank-Betrieb willst	Pinecone
Hybrid-Suche und GraphQL-API out-of-the-box brauchst	Weaviate
Schnellen Embedded-Vektor-Speicher für Prototypen suchst	Chroma
Embeddings über ein vollständiges Framework verwalten willst	LangChain
Indexbau und Embedding-Erzeugung lokal kombinieren willst	Ollama

Erwähnenswert ohne eigene Tool-Seite: Qdrant (Rust-basiert, hervorragende Filter-Performance, Self-Hosting und Cloud), Milvus (verteilte Architektur, für Massendaten ausgelegt, von Zilliz betrieben), FAISS von Meta (in-process Bibliothek, kein Server, ideal für embedded Use-Cases), LanceDB (spaltenorientierter Vektor-Speicher mit starkem Versioning) und Vespa (Yahoo-Ursprung, Such- und Vektor-Plattform für Großanwendungen). Innerhalb des Postgres-Ökosystems gibt es noch pgvecto.rs (in Rust geschriebene Alternative mit Fokus auf Performance) und Timescale Vector (auf TimescaleDB aufsetzend, mit Disk-ANN-Index-Variante). Pgvector bleibt aber der klare De-facto-Standard in Postgres und wird von praktisch allen großen Cloud-Anbietern und Tools als Default-Option behandelt.

So steigst du ein

Schritt 1: Erweiterung aktivieren — eine Zeile SQL. In einer beliebigen Postgres-Instanz (Version 13+): CREATE EXTENSION vector;. Auf Managed-Diensten (Supabase, Neon, RDS) musst du die Erweiterung gegebenenfalls vorher in der Cloud-Konsole „erlauben” — danach ist sie wie jede andere Postgres-Funktion verfügbar. Lege dann eine Tabelle an: CREATE TABLE items (id bigserial PRIMARY KEY, content text, embedding vector(1536)); (1.536 für OpenAI text-embedding-3-small).

Schritt 2: Embeddings erzeugen und einfügen. Generiere Embeddings über OpenAI, Cohere oder ein lokales Modell und füge sie ein: INSERT INTO items (content, embedding) VALUES ('Mein Text', '[0.1, 0.2, ...]');. Für Tausende von Embeddings nimm COPY oder Batch-Inserts — sequenzielle Einzel-Inserts sind langsam. Faustregel: 1.000 Vektoren pro Batch ist ein vernünftiger Startpunkt.

Schritt 3: Index aufbauen, wenn die Datenmenge wächst. Bei wenigen tausend Vektoren ist Brute-Force (kein Index) absolut ausreichend und meistens sogar schneller. Ab etwa zehntausend Vektoren lohnt sich ein HNSW-Index: CREATE INDEX ON items USING hnsw (embedding vector_cosine_ops);. Achtung: Bei großen Tabellen kann der Build Stunden dauern — maintenance_work_mem vorher hochsetzen (SET maintenance_work_mem = '4GB';) und gegebenenfalls in den Wartungs-Zeitfenstern bauen.

Schritt 4: Suchen mit der richtigen Distanz-Funktion. Drei Hauptoperatoren: <-> (L2 / Euklidisch), <#> (Inner Product, negativ), <=> (Cosinus). Für die meisten Embedding-Modelle (OpenAI, Cohere, Sentence-Transformers) ist Cosinus-Distanz die richtige Wahl: SELECT * FROM items ORDER BY embedding <=> '[0.1, 0.2, ...]' LIMIT 10;. Wichtig: Der Index muss mit der passenden Operator-Klasse (vector_cosine_ops für <=>) gebaut werden, sonst wird er ignoriert.

Ein konkretes Beispiel

Ein Berliner SaaS-Anbieter (B2B-Dokumentenmanagement, 30 Mitarbeitende, 2.500 Mandanten-Workspaces) baut eine semantische Suchfunktion in seine bestehende Anwendung ein. Architektur: PostgreSQL läuft ohnehin als Hauptdatenbank auf AWS RDS in Frankfurt (eu-central-1) — die zentrale Tabelle documents enthält bereits 4,2 Millionen Dokument-Einträge mit Mandanten- und Berechtigungs-Metadaten. pgvector-Integration: CREATE EXTENSION vector; in der bestehenden Datenbank, neue Spalte embedding vector(1536), Embeddings über Azure OpenAI in der EU-Region erzeugt und nachträglich für alle Bestandsdokumente befüllt (nächtlicher Batch-Job, 6 Stunden Laufzeit). HNSW-Index: Aufgebaut mit m=16, ef_construction=64 während eines Wartungsfensters — Dauer 2,5 Stunden, 12 GB zusätzlicher Index-Speicherbedarf. Suchanfrage: SELECT id, title FROM documents WHERE workspace_id = $1 AND embedding <=> $2::vector LIMIT 10; — durch den Index unter 80 ms p95 trotz Mandanten-Filter. Spürbarer Effekt: Statt einer separaten Pinecone-Instanz (geschätzte Mehrkosten 200–400 USD/Monat plus Daten-Synchronisation) läuft alles in der bestehenden Infrastruktur. Backups, Replikation und Disaster-Recovery sind unverändert. Aufwand: Ein Senior-Entwickler, ca. 1,5 Wochen für funktionsfähige Erstversion plus 1 Woche für Tuning und Lasttests.

DSGVO & Datenschutz

• Erweiterung selbst: pgvector ist eine Open-Source-Bibliothek (MIT-Lizenz), die in deiner eigenen Postgres-Instanz läuft — die DSGVO-Bewertung hängt allein davon ab, wo deine Datenbank gehostet wird und welche Embedding-Modelle du aufrufst.
• EU-Hosting problemlos möglich: Auf AWS RDS Postgres (eu-central-1 Frankfurt), Azure Database for PostgreSQL (Germany West Central), Google Cloud SQL (europe-west), Supabase (eu-central-1), Neon (eu-central-1) sowie auf jeder selbst gehosteten Postgres-Instanz in EU-Rechenzentren (Hetzner, OVH, IONOS) ist DSGVO-konformes Hosting trivial möglich.
• Datennutzung: Da pgvector als Erweiterung in deiner Datenbank läuft, fließen keinerlei Daten an Andrew Kane oder Dritte ab. Es gibt keine Telemetrie, keine externen API-Aufrufe, keine Phone-Home-Funktion.
• Auftragsverarbeitung (AVV): Nicht relevant für die Erweiterung selbst. Wenn du einen Managed-Postgres-Anbieter nutzt (RDS, Supabase, Neon), ist der jeweilige Anbieter dein AVV-Partner — nicht das pgvector-Projekt.
• Embedding-Erzeugung beachten: Achtung — die Erzeugung der Embeddings (vor dem Insert in pgvector) findet außerhalb der Datenbank statt. Wer die OpenAI-API in den USA aufruft, übermittelt dafür Klartext-Inhalte an OpenAI. Saubere DSGVO-Architektur: Embeddings über Azure OpenAI in EU-Region oder über lokale Modelle (Sentence-Transformers, Ollama) erzeugen.
• Empfehlung für Unternehmen: pgvector ist eine der DSGVO-freundlichsten Optionen am Markt — vorausgesetzt, die Embedding-Pipeline davor wird ebenfalls EU-konform aufgebaut. Für reguliertere Branchen (Gesundheit, Recht, Finanzen) ist pgvector auf Self-Hosted-Postgres oft der einzige Weg, der ohne weitere Vertragswerke auskommt.

Gut kombiniert mit

• LangChain — pgvector ist als PGVector-Vector-Store nativ integriert. Kombiniert ergibt sich eine vollständige RAG-Pipeline: LangChain orchestriert Embedding-Erzeugung, Retrieval und Generation, pgvector liefert den Speicher. Das ist der Standard-Stack für Postgres-basierte RAG-Anwendungen.
• Hugging Face — kostenlose Open-Source-Embedding-Modelle (z. B. all-MiniLM-L6-v2 mit nur 384 Dimensionen, sehr schnell) lassen sich lokal ausführen und in pgvector speichern. Kombination ist die günstigste vollständig kostenfreie und DSGVO-konforme RAG-Variante.
• Ollama — wenn Embeddings lokal in der eigenen Infrastruktur erzeugt werden sollen, liefert Ollama Embedding-Modelle (z. B. nomic-embed-text) per HTTP-API. In Kombination mit pgvector entsteht ein vollständig lokaler Stack ohne externe Abhängigkeiten — ideal für Air-Gapped- oder hochsensible Deployments.

Unser Testurteil

pgvector verdient 5 von 5 Sternen. Es ist nicht in jeder einzelnen Disziplin die beste Vektor-Lösung — bei Milliarden-Vektoren mit harten Latenz-SLAs sind Milvus oder spezialisierte Pinecone-Setups überlegen, bei eingebauter Hybrid-Suche ist Weaviate ausgereifter. Aber pgvector beantwortet die zentrale Architektur-Frage richtig: „Brauche ich wirklich eine zweite Datenbank im Stack?” — und für 90 % der real gebauten Anwendungen lautet die ehrliche Antwort: nein. Hinzu kommen die offene MIT-Lizenz, die universelle Verfügbarkeit auf allen Managed-Postgres-Diensten, die ACID-Konsistenz mit relationalen Daten, das vollständig EU-kompatible Hosting und die aktive Entwicklung mit breiter Toolchain-Integration. Für jedes Team, das PostgreSQL bereits einsetzt und vor der Frage steht „wie speichere ich Embeddings?”, ist pgvector die rationale Erstwahl — und in den meisten Fällen die einzige nötige Wahl. Andrew Kane hat mit dieser Erweiterung das Vektor-Datenbank-Problem für die überwältigende Mehrheit der Anwender vom Tisch geräumt.

Was wir bemerkt haben

• 2021 — Andrew Kane veröffentlichte die erste Version von pgvector. Was als Solo-Open-Source-Projekt startete, wurde innerhalb von drei Jahren zur De-facto-Vektor-Schnittstelle für PostgreSQL — adoptiert von AWS, Azure, Google Cloud, Supabase und Neon.
• Juli 2023 — pgvector v0.5.0 brachte den HNSW-Index, der den älteren IVFFlat-Index in den meisten Workloads ablöste. Recall-Werte und Anfragelatenzen verbesserten sich dramatisch — ein echter Wendepunkt für die Praxistauglichkeit.
• 2023 — AWS, Azure und Google Cloud nahmen pgvector innerhalb weniger Monate in ihre Managed-Postgres-Angebote auf. Damit wurde aus einem Nischen-Tool quasi über Nacht eine Standard-Komponente in jeder modernen Cloud-Postgres-Instanz.
• 2024 — pgvector v0.7.0 führte neue Vektor-Typen ein: halfvec (16-Bit Float, halber Speicher), bit (binäre Vektoren) und sparsevec (für seltene Vektoren). Damit wurde Speicher- und Performance-Tuning erheblich flexibler — besonders bei großen Embedding-Mengen relevant.
• 2025 — Mit pgvector v0.8.0 kam iterative Index-Suche (hnsw.iterative_scan), die das alte Problem schlechter Filterung bei kombinierten Anfragen (WHERE + Vektor-Suche) deutlich entschärft. Damit nähert sich pgvector funktional an dedizierte Vektordatenbanken wie Qdrant an.
• Mai 2026 — Pgvector bleibt vollständig Open-Source unter MIT-Lizenz und hat keinen kommerziellen Anbieter im Hintergrund — eine Seltenheit in der Vektor-Datenbank-Welt, in der die meisten Konkurrenten Venture-finanziert sind. Andrew Kane pflegt das Projekt weiterhin aktiv, unterstützt von einer wachsenden Contributor-Basis. Die fehlende EU-Region ist hier kein Thema — pgvector läuft, wo PostgreSQL läuft.