Vektorsuche in Produktion: pgvector vs. spezialisierte Vektordatenbanken
Die Wahl eines Vektorsuche-Backends sollte einen Nachmittag dauern. Stattdessen verbringen die meisten Teams Wochen damit, sich widersprechende Benchmark-Beitraege zu lesen, Vendor-Demos beizuwohnen und am Ende die Option mit dem schoensten Dashboard auszuwaehlen. Dann bauen sie die Entscheidung sechs Monate spaeter neu, wenn der Produktionsbetrieb offenbart, was die Benchmarks nicht gezeigt haben.
Dieser Beitrag handelt davon, diese Wahl beim ersten Mal richtig zu treffen. Die Kurzfassung: pgvector ist die richtige Antwort fuer die meisten SaaS-Produkte, und die Schwellenwerte, bei denen eine spezialisierte Vektordatenbank genuinen Mehrwert liefert, sind spezifischer als das Vendor-Marketing vermuten laesst. Wir gehen diese Schwellenwerte konkret durch und geben dir die Kriterien an die Hand, um sie auf deine eigene Arbeitslast anzuwenden.
Was Vektorsuche auf Infrastrukturebene tatsaechlich bedeutet
Bevor wir Optionen vergleichen, lohnt es sich, prazise zu beschreiben, was genau du waehlen musst.
Vektorsuche findet die k naechsten Nachbarn zu einem Abfrage-Embedding in einer gespeicherten Kollektion von Vektoren. Die zwei dominanten Indextypen sind:
- HNSW (Hierarchical Navigable Small World): Ein graphbasierter Index. Schnell zur Abfragezeit, speicherhungrig zur Build-Zeit, hervorragender Recall. Der dominante Ansatz in 2026.
- IVFFlat (Inverted File Index): Clustert Vektoren in Eimer und durchsucht eine Teilmenge. Geringerer Speicherbedarf, schnelleres Aufbauen, schlechterer Recall, sofern der
nprobes-Parameter nicht sorgfaeltig angepasst wird.
Sowohl pgvector als auch jede spezialisierte Vektordatenbank unterstuetzen HNSW. Die Unterschiede liegen darin, wie gut jedes System die umgebenden Belange behandelt: Transaktionskonsistenz mit deinen relationalen Daten, Index-Update-Durchsatz, operativer Aufwand und Kosten bei der Skalierung, die du tatsaechlich betreibst.
pgvector: Der Fall fuer den Einstieg hier
pgvector ist eine PostgreSQL-Extension. Du speicherst Vektoren als Spaltentyp neben dem Rest deiner relationalen Daten. Du fragst mit <-> (L2-Distanz), <=> (Kosinus-Distanz) oder <#> (inneres Produkt) ab.
SELECT id, content, embedding <=> query_embedding AS distance
FROM documents
WHERE user_id = $1
ORDER BY distance
LIMIT 10;
Das ist alles. Kein separater Service. Kein Synchronisierungsjob. Keine separate Authentifizierungsschicht. Keine zusaetzlichen Infrastrukturkosten, bis du ueberschreitest, was eine gut konfigurierte Postgres-Instanz leisten kann.
Wo pgvector genuinen Mehrwert bietet
Transaktionskonsistenz. Wenn ein Nutzer ein Dokument loescht, verschwindet die Zeile sofort aus den Vektorsuche-Ergebnissen - innerhalb derselben Transaktion. Mit jeder spezialisierten Vektordatenbank hast du nun ein Eventual-Consistency-Problem. Du benotigst einen Loeschungs-Propagierungsmechanismus und musst ihn unter Fehlerbedingungen testen. Das ist kein Grund, nie einen spezialisierten Store zu verwenden, aber es sind echte Engineering-Kosten, die Benchmarks nicht erfassen.
Metadaten-Filterung. Hybridabfragen, die vor oder nach der Vektorsuche auf relationale Attribute filtern, sind erstklassiges SQL. In Postgres ist eine Abfrage wie "finde die 10 aehnlichsten Dokumente zu diesem Embedding, geschrieben von Nutzern in der Enterprise-Stufe, erstellt in den letzten 90 Tagen" ein Standard-Query-Planer-Problem. In den meisten spezialisierten Vektordatenbanken ist Metadaten-Filterung ein nachtraegliches Feature mit subtil unterschiedlicher Semantik und Performance-Charakteristiken je nach Filter-Selektivitaet.
Operative Einfachheit. Dein Team betreibt bereits Postgres. Du hast bereits Backup-Verfahren, Monitoring, Zugriffssteuerung und Runbooks dafuer. pgvector hinzufuegen bedeutet, eine Extension und einen Spaltentyp hinzuzufuegen - keine neue Infrastrukturschicht mit eigenen Fehlermodi.
Kosten bei moderater Skalierung. Eine gut provisionierte Postgres-Instanz mit pgvector auf einem 4-Kern/32-GB-Node bewaltigt 5-10 Millionen Vektoren mit HNSW und sub-50ms-p99-Abfragelatenz fuer typische SaaS-Arbeitslasten problemlos. Zum Vergleichspreis von Pinecone wuerde gleichwertige Performance 3-5x mehr pro Monat kosten. Dieser Unterschied ist in fruehen Wachstumsphasen relevant.
Die ehrlichen Einschraenkungen
pgvectors HNSW-Implementierung hat sich mit jeder Version erheblich verbessert, hat aber echte Grenzen:
- Speicheranforderungen. HNSW-Indizes werden fuer schnelle Abfrage-Performance vollstaendig in den Speicher geladen. Bei 10M+ Vektoren mit hochdimensionalen Embeddings (1536 Dimensionen fuer OpenAIs
text-embedding-3-small) verbraucht dein Index Dutzende Gigabyte. Das ist handhabbar, formt aber deine Instanz-Groesse. - Index-Build-Zeit. Das Aufbauen eines HNSW-Indexes auf 50M+ Vektoren ist eine mehrtuendige Operation, die gleichzeitige Updates auf dieser Spalte blockiert. Spezialisierte Datenbanken behandeln Live-Index-Updates eleganter.
- Durchsatz unter schweren gleichzeitigen Schreibvorgaengen. Bei hohen Einraten (Tausende von Vektoren pro Sekunde) erzeugt der allgemeine Schreibpfad von Postgres Contention, die spezialisierte Systeme durch zielgerichtete Ingest-Pipelines vermeiden.
Spezialisierte Vektordatenbanken: Pinecone, Weaviate, Qdrant
Die spezialisierten Optionen haben jeweils eine eigene Positionierung:
Pinecone ist die ausschliesslich verwaltete Option - kein Self-Hosting. Es ist operativ die einfachste der spezialisierten Datenbanken mit einer sauberen API und starken verwalteten Infrastrukturgarantien. Der Kompromiss ist Kosten und Lock-in. Die Preisgestaltung ist verbrauchsbasiert und steigt schnell uber 10M Vektoren mit signifikantem Abfragedurchsatz.
Weaviate ist Open Source mit einer verwalteten Cloud-Option. Es kombiniert Vektorsuche mit einem graphaehnlichen Objektmodell, das fuer Knowledge-Graph-Anwendungsfaelle attraktiv ist, aber konzeptionellen Overhead fuer Teams hinzufuegt, die nur Naechster-Nachbar-Suche wollen. Starke multimodale Unterstuetzung (Bilder, Audio), wenn das fuer dein Produkt relevant ist.
Qdrant ist Open Source, in Rust geschrieben und hat sich als staerkste Self-Hosted-Option in Bezug auf Performance und operative Einfachheit etabliert. Es unterstuetzt sparse Vektoren neben dense Vektoren nativ, was hybride BM25+Vektor-Suche unkompliziert macht. Fuer Teams, die eine spezialisierte Vektordatenbank ohne Pinecones Preisgestaltung wollen, ist Qdrant in 2026 meistens die richtige Wahl.
Wann eine spezialisierte Datenbank sich tatsaechlich lohnt
Die Faelle, in denen spezialisierte Vektordatenbanken die zusaetzliche operative Schicht genuinen rechtfertigen:
Kollektionen ueber ~50M Vektoren. Bei dieser Skalierung werden das allgemeine Speicherformat und der Schreibpfad von Postgres zu echten Engpaessen. Spezialisierte Datenbanken optimieren das Speicherlayout speziell fuer Vektordaten und behandeln Index-Updates bei diesem Volumen eleganter.
Ingest-Durchsatz ueber ~1.000 Vektoren/Sekunde dauerhaft. Wenn dein Produkt Dokumente oder Events mit hoher Geschwindigkeit einliest - Echtzeit-Benutzeraktivitaets-Streams, kontinuierliche Dokumentenverarbeitungs-Pipelines - verarbeiten spezialisierte Systeme das sauberer. Sie sind um die Annahme herum gebaut, dass dein Schreibpfad vektorlastig ist.
Mandantenfaehigkeit bei extremer Skalierung. Wenn du eine Plattform baust, bei der jeder Mandant einen separaten Embedding-Namespace mit Dutzenden von Millionen Vektoren hat, haben spezialisierte Systeme erstklassige Namespace/Collection-Isolation. pgvector erfordert, dass du das mit Zeilenebenen-Filterung handhabst, was Abfragekomplexitaet hinzufuegt.
Suche als Kernprodukt. Wenn Aehnlichkeitssuche deine primaere Produktoberflaeche ist - kein unterstuetzendes Feature fuer einen KI-Assistenten oder Dokumentenabfrage - sind die zusaetzlichen Tuning-Kontrollen in spezialisierten Datenbanken (HNSW-Parameter-Tuning, Quantisierungsoptionen, hybride Reranking-Pipelines) das Erlernen wert.
Hybridsuche: BM25 + Vektor
Die meisten Produktions-Retrieval-Systeme profitieren von der Kombination aus Sparse-Keyword-Suche (BM25) und dense Vektorsuche. Reine semantische Aehnlichkeit verfehlt exakte Treffer-Abfragen ("Was bedeutet Feld X in unserer API-Antwort?"), die Keyword-Suche besser behandelt.
In pgvector kannst du Hybridsuche implementieren, indem du einen ts_vector-Volltext-Suche-Score mit dem Vektor-Distanz-Score durch eine gewichtete Kombination oder RRF (Reciprocal Rank Fusion) kombinierst. Das ist in SQL vollstaendig erreichbar, erfordert aber bewusste Abfragekonstruktion.
Qdrant hat native Sparse-Vektor-Unterstuetzung, die BM25+Vektor-Hybridsuche zu einer erstklassigen Operation macht. Weaviate und Pinecone unterstuetzen ebenfalls Hybridsuche-Modi.
Wenn Hybridsuche zentral fuer deine Retrieval-Architektur ist - nicht nur ein Nice-to-have - ist das der eine Bereich, in dem spezialisierte Datenbanken heute eine merklich bessere Entwicklererfahrung als pgvector bieten.
Bewertungsmetriken, die tatsaechlich zaehlen
Bei der Bewertung der Retrieval-Qualitaet sind die Standardmetriken:
- Recall@k: Von den echten k naechsten Nachbarn, wie viele gibt der Index tatsaechlich zurueck? HNSW erreicht typischerweise 95-99% Recall mit Standardeinstellungen; IVFFlat erfordert Tuning.
- p95/p99-Abfragelatenz: Median-Latenz ist irreführend. Was fuer nutzernahe Features zaehlt, ist der Schwanz.
- Index-Build-Zeit und Online-Update-Latenz: Wie lange dauert es, bis hinzugefuegte Vektoren durchsuchbar sind?
Die wichtigste Bewertung, die die meisten Teams ueberspringen: Ende-zu-Ende-Retrieval-Qualitaet auf deinen tatsaechlichen Daten, mit deinen tatsaechlichen Abfragen. Generische Benchmarks verwenden synthetische Datensaetze. Die Dokumente deiner Nutzer und Abfragemuster koennen sehr unterschiedliche Charakteristiken haben. Erstelle ein kleines Evaluierungs-Set aus echten Produktionsabfragen, bevor du dich auf einen Indextyp oder ein Backend festlegst.
Ein pragmatischer Entscheidungspfad
Ein neues Projekt starten oder Vektorsuche zu einem bestehenden System hinzufuegen:
- Standardmaessig pgvector verwenden. Du brauchst beim Launch fast sicher nichts anderes. Damit ausliefern, messen und ueberdenken, wenn du echte Produktionsdaten hast.
- Bei 10M+ Vektoren neu bewerten, wenn du Abfrage-Latenzprobleme, hohen Index-Speicherdruck oder Ingest-Durchsatz-Engpaesse erlebst. Diese Metriken von Tag eins an instrumentieren, damit die Neubewertung datengetrieben ist.
- Qdrant waehlen, wenn du von pgvector migrierst und Self-Hosted betreiben moechtest. Es hat das beste Performance/operativer-Komplexitaets-Verhaeltnis unter den Self-Hosted-Optionen und native Unterstuetzung fuer die Hybridsuche-Muster, die du wahrscheinlich benoetigen wirst.
- Pinecone waehlen, wenn dein Team keine Kapazitaet hat, Vektorinfrastruktur zu betreiben, und du verwaltete Zuverlaessigkeitsgarantien mit vorhersehbaren SLAs benotigst.
Von pgvector zu einem spezialisierten Store migrieren (wenn die Zeit kommt)
Wenn du mit pgvector beginnst und spaeter migrieren musst, ist der Pfad im Prinzip unkompliziert:
- Embeddings aus Postgres mit ihren zugehoerigen IDs exportieren.
- Massen-Ingest in den neuen Store.
- Deine Evaluierungs-Suite gegen beide Backends parallel ausfuehren, bevor du umschaltest.
- Die Postgres-Fremdschluessel-Struktur beibehalten; der neue Store haelt nur die Vektoren und IDs, nicht deine relationalen Daten.
Das groesste Migrationsrisiko ist, dass deine Metadaten-Filterungsabfragen, die in SQL natuerlich funktionieren, in die Abfrage-API des neuen Systems uebersetzt werden muessen. Diesen Uebersetzungsaufwand im Voraus einplanen - er ist selten so einfach, wie die Migrationsleitfaeden suggerieren.
Was das fuer deine Architektur bedeutet
Wenn du ein KI-gestuetztes SaaS-Produkt mit Dokumentenabfrage, semantischer Suche oder Embedding-basierter Personalisierung baust, ist der richtige Ausgangspunkt pgvector innerhalb deiner bestehenden Postgres-Datenbank.
Eine vector(1536)-Spalte hinzufuegen. Deinen HNSW-Index aufbauen. Deine Retrieval-Abfragen in SQL neben deinen anderen Abfragen schreiben. Die operative Angriffslaeche deines Produkts minimal halten, waehrend du Product-Market-Fit findest und deine tatsaechlichen Zugriffsmuster kennenlernst.
Das Gespraech ueber spezialisierte Vektordatenbanken wird produktiv, sobald du echte Produktionsdaten hast, die dir zeigen, wo die Einschraenkungen von pgvector fuer deine spezifische Arbeitslast tatsaechlich relevant sind - nicht vorher.
Wenn du deine Vektorsuche-Architektur evaluierst oder einen KI-Feature-Stack aufbaust und eine unabhaengige Einschaetzung der Kompromisse fuer deine spezifische Situation moechtest, helfen wir gerne. Melde dich unter hello@wolf-tech.io oder ueber wolf-tech.io.
Haeufig gestellte Fragen
Ist pgvector in 2026 produktionsreif? Ja. Mit den juengsten HNSW-Verbesserungen und korrektem Tuning behandelt pgvector die Vektorsuche-Arbeitslasten der grossen Mehrheit der SaaS-Produkte ohne Probleme. Die Haupteinschraenkungen - Speicheranforderungen fuer grosse Indizes und Ingest-Durchsatzlimits - werden nur bei Skalierungsschwellenwerten relevant, die die meisten Produkte in den ersten Jahren nicht erreichen.
Welche Embedding-Dimensionen unterstuetzt pgvector?
pgvector unterstuetzt bis zu 2.000 Dimensionen. OpenAIs text-embedding-3-small verwendet 1.536 Dimensionen; text-embedding-3-large kann auf 256-1.536 Dimensionen reduziert werden. Anthropic- und Cohere-Embeddings liegen innerhalb des Limits.
Kann ich hybride BM25+Vektor-Suche in pgvector betreiben?
Ja, durch Kombination der eingebauten ts_vector-Volltext-Suche von Postgres mit den Distanzoperatoren von pgvector. Die Abfrage ist ausfuehrlicher als Qdrants nativer Hybridmodus, aber voll funktionsfaehig und vermeidet einen separaten Service.
Wann sollte ich Pinecone statt Qdrant verwenden? Pinecone ist die bessere Wahl, wenn dein Team keine Kapazitaet hat, Self-Hosted-Infrastruktur zu betreiben, und du vollstaendig verwaltete Zuverlaessigkeit benotigst. Qdrant ist die bessere Wahl, wenn du bereit bist, einen Service zu betreiben, und Pinecones Pro-Abfrage-Preisgestaltung bei Skalierung vermeiden moechtest.
Wie verhaelt sich pgvector im Vergleich zu Pinecone? Auf aequivalenter Hardware erreicht ein gut konfigurierter pgvector-HNSW-Index vergleichbaren Recall und Abfragelatenz wie Pinecone fuer Kollektionen unter ~20M Vektoren. Ueber diesem Schwellenwert zeigt Pinecones zielgerichtete Infrastruktur typischerweise hoeheren Durchsatz unter gleichzeitiger Last.