Vektordatenbank waehlen: pgvector, Pinecone und Weaviate im Vergleich

pgvector, Pinecone oder Weaviate: Dieser Vergleich zeigt dir anhand von Betrieb, Kosten und Hybrid-Suche, welche Vektordatenbank zu deinem RAG-Projekt passt, statt dich in Benchmark-Folien zu verlieren.

Warum die Wahl ueberhaupt zaehlt

Sobald du einen RAG-Wissensbot, eine semantische Produktsuche oder einen KI-gestuetzten Support baust, brauchst du einen Ort, an dem deine Embeddings liegen und in Millisekunden durchsucht werden. Drei Kandidaten tauchen im DACH-Mittelstand immer wieder auf: pgvector (eine Postgres-Erweiterung), Pinecone (ein gehosteter Dienst) und Weaviate (Open Source, wahlweise selbst betrieben oder als Cloud).

Die ehrliche Wahrheit vorweg: Fuer die meisten Projekte unter etwa fuenf Millionen Vektoren ist die Suchqualitaet zwischen den dreien nahezu identisch, weil alle den gleichen HNSW-Algorithmus nutzen. Der Unterschied liegt woanders, naemlich im Betrieb, in den laufenden Kosten und in der Frage, ob du Vektor- und Filterlogik in einer Datenbank oder in zwei getrennten Systemen halten willst. Genau darauf schaut dieser Artikel.

pgvector: alles in deinem Postgres

pgvector ist eine Erweiterung fuer PostgreSQL. Du legst eine Spalte vom Typ vector(1536) an, spielst deine Embeddings hinein und suchst mit Distanz-Operatoren: <=> fuer Cosine, <-> fuer L2 und <#> fuer das innere Produkt. Fuer schnelle Suche baust du einen HNSW-Index, zum Beispiel CREATE INDEX ON docs USING hnsw (embedding vector_cosine_ops).

Der grosse Vorteil: Deine Vektoren liegen neben deinen normalen Daten. Du kannst in einer einzigen Query nach Aehnlichkeit sortieren und gleichzeitig per WHERE tenant_id = $1 AND status = 'live' filtern, alles transaktional, alles mit deinen bestehenden Backups. Wenn du ohnehin Postgres (oder Supabase, wo pgvector vorinstalliert ist) faehrst, kommst du ohne ein zweites System aus.

Die Grenzen solltest du kennen. Der HNSW-Index unterstuetzt bis zu 2000 Dimensionen pro Spalte, mit dem Typ halfvec bis 4000. Ab einigen Millionen Vektoren wird der Indexaufbau spuerbar, und du musst Parameter wie m, ef_construction und zur Laufzeit hnsw.ef_search selbst tunen. pgvector skaliert genau so weit, wie deine Postgres-Instanz Arbeitsspeicher hat.

Pinecone: Betrieb komplett abgeben

Pinecone ist ein gehosteter Vektordienst. Du bekommst keine Datenbank zum Anfassen, sondern eine API, in die du Vektoren mit Metadaten schreibst (upsert) und wieder abfragst (query). Skalierung, Sharding und Indexpflege laufen im Hintergrund. Das serverless Modell rechnet nach Read- und Write-Units plus Speicher, sodass du bei wenig Traffic wenig zahlst und nicht dauerhaft eine Instanz vorhalten musst.

Der Reiz ist der geringe Betriebsaufwand. Du musst keinen Index tunen, kein Autovacuum beobachten und keine Replikation aufsetzen. Fuer ein kleines Team ohne dedizierten Datenbank-Verantwortlichen ist das oft die schnellste Strecke zu einem stabilen System, das auch bei Lastspitzen haelt.

Der Preis dafuer ist Kontrollverlust und Datenlage. Deine Embeddings liegen bei einem US-Anbieter, was fuer viele DACH-Kunden eine DSGVO-Bewertung noetig macht. Ausserdem sind Vektoren und deine restlichen Geschaeftsdaten getrennt: Willst du Ergebnisse mit Live-Bestand oder Berechtigungen verschneiden, brauchst du danach immer noch einen Roundtrip in deine eigene Datenbank. Metadaten-Filter kann Pinecone zwar, aber die Wahrheit ueber deine Domaene bleibt woanders.

Weaviate: Suche als eigenes Produkt

Weaviate ist eine Open-Source-Vektordatenbank, die du im eigenen Kubernetes oder per Docker betreibst oder als Weaviate Cloud buchst. Du modellierst deine Daten als Klassen mit Properties, suchst per GraphQL oder REST und bekommst von Haus aus mehr Suchfunktionen als bei den anderen beiden.

Das staerkste Argument ist die eingebaute Hybrid-Suche: Weaviate kombiniert Vektoraehnlichkeit mit klassischem BM25-Keyword-Ranking und fusioniert beide Trefferlisten. Genau das brauchst du, wenn Nutzer nach exakten Begriffen wie Artikelnummern, Eigennamen oder Fehlercodes suchen, die ein reines Embedding gerne verwaschen. Ueber optionale Module kann Weaviate Embeddings auch selbst erzeugen, sodass du den Aufruf zum Embedding-Modell nicht separat orchestrieren musst.

Der Preis ist Komplexitaet. Weaviate ist ein zusaetzliches, zustandsbehaftetes System, das du versionieren, sichern und ueberwachen musst. Betreibst du es selbst, kaufst du dir Flexibilitaet und Datenhoheit ein, bezahlst aber mit Betriebsaufwand, der sich erst ab ernsthafter Skala oder echtem Hybrid-Bedarf lohnt.

Die Entscheidungskriterien nebeneinander

Statt Benchmark-Folien zu vergleichen, geh die Fragen durch, die im Betrieb wirklich weh tun:

• Betrieb: pgvector faehrt in deinem vorhandenen Postgres mit. Pinecone hat null Betrieb, laeuft aber fremd. Weaviate ist ein eigenes System mit eigenem Lebenszyklus.
• Datenhoheit und DSGVO: pgvector und selbst gehostetes Weaviate liegen dort, wo du willst (etwa EU). Pinecone und Weaviate Cloud bedeuten Auftragsverarbeitung durch Dritte.
• Filter und Joins: Nur pgvector verbindet Aehnlichkeit und Geschaeftslogik in einer transaktionalen Query. Bei Pinecone und Weaviate filterst du zwar auf Metadaten, hast aber keinen echten Join in deine Stammdaten.
• Hybrid-Suche: Weaviate liefert BM25 plus Vektor fertig. Bei pgvector baust du das ueber die Volltextsuche tsvector plus Vektorspalte selbst, was gut funktioniert, aber Handarbeit ist.
• Skalierung: Ab grob zehn Millionen Vektoren mit hoher Query-Rate spielen Pinecone und Weaviate ihre Sharding-Staerken aus, waehrend pgvector mehr Tuning und RAM verlangt.

Konkrete Empfehlung nach Szenario

Wenn du schon Postgres oder Supabase nutzt und unter wenigen Millionen Vektoren bleibst, starte mit pgvector. Du sparst dir ein ganzes System, hast deine Daten an einem Ort und kannst Aehnlichkeit mit Berechtigungen und Live-Zustand in einer Query verschneiden. Das deckt den Grossteil der RAG-Projekte im Mittelstand ab.

Wenn dein Team keinen Datenbank-Betrieb stemmen will und die DSGVO-Bewertung fuer einen US-Dienst sauber geklaert ist, ist Pinecone der schnellste Weg zu etwas Stabilem. Du kaufst dir Zeit, zahlst dafuer mit Fremdbetrieb und einem getrennten Datentopf.

Wenn exakte Keyword-Treffer neben semantischer Aehnlichkeit ueber Erfolg entscheiden, etwa in einer grossen Produkt- oder Dokumentensuche, und du Datenhoheit brauchst, nimm selbst gehostetes Weaviate. Die eingebaute Hybrid-Suche spart dir echten Entwicklungsaufwand, sobald reine Vektorsuche an ihre Grenzen kommt.

Migration einplanen, nicht sich festlegen

Die gute Nachricht: Die Wahl ist selten endgueltig. Deine Embeddings sind nur Listen von Fliesskommazahlen, und die eigentliche Logik (Chunking, welches Embedding-Modell, wie du Kontext an das Sprachmodell reichst) lebt in deinem Code, nicht in der Datenbank. Kapsle den Zugriff hinter einem schmalen Interface mit Methoden wie upsert und search, dann tauschst du das Backend spaeter mit ueberschaubarem Aufwand.

Ein praktischer Pfad fuer viele Teams: Du startest mit pgvector, misst reale Query-Zeiten und Datenmengen und wechselst erst dann zu Pinecone oder Weaviate, wenn eine harte Grenze sichtbar wird. So triffst du die Entscheidung mit Zahlen aus deinem eigenen Betrieb statt mit Marketing-Versprechen, und du zahlst die Komplexitaet eines zweiten Systems erst, wenn sie sich wirklich rechnet.