pgvector vs. Pinecone: Was KMU wirklich brauchen

Die Ausgangslage: Warum überhaupt Vektoren?

Semantische Suche, RAG-Pipelines, Dokumentenähnlichkeit – all das braucht eine Möglichkeit, hochdimensionale Embeddings zu speichern und effizient abzufragen. Die Frage, die sich im KMU-Kontext stellt, ist nicht philosophisch: Sie lautet, ob man eine dedizierte Vektordatenbank braucht oder ob die bestehende Postgres-Instanz mit dem pgvector-Extension ausreicht.

Meine kurze Antwort: Für 80 % der KMU-Anwendungsfälle reicht pgvector. Für den Rest nicht – und das „nicht” kommt schneller, als man denkt.

Was pgvector kann und was nicht

pgvector ist eine Open-Source-Extension für PostgreSQL. Sie fügt einen neuen Datentyp vector hinzu und bringt Indexierungsverfahren wie IVFFlat und HNSW mit. Seit Version 0.5.0 (Ende 2023) ist HNSW der empfohlene Index für die meisten Workloads – Annäherungsgenauigkeit und Abfragegeschwindigkeit sind damit deutlich besser als mit IVFFlat.

Was funktioniert gut:

• Sammlungen bis ca. 1–2 Millionen Vektoren mit 1.536 Dimensionen (OpenAI text-embedding-3-small)
• Abfragen unter 100 ms bei moderater Last (< 50 gleichzeitige Requests)
• Kombination aus Vektor-Ähnlichkeitssuche und klassischen SQL-Filtern in einer einzigen Query
• Betrieb auf bestehender Postgres-Infrastruktur – kein zusätzlicher Stack
• Volle Transaktionssicherheit, ACID-Garantien, vertrautes Backup-Prozedere

Wo es eng wird:

• Kollektionen über 5 Millionen Vektoren: Der HNSW-Index wird speicherhungrig. 1 Million Vektoren à 1.536 Dimensionen belegen rund 6 GB RAM im Index allein.
• Mehr als 200–300 gleichzeitige Vektorabfragen: Postgres ist kein spezialisierter ANN-Server. Der Thread-Pool skaliert nicht wie ein dedizierter Dienst.
• Dynamische Embedding-Updates in hoher Frequenz: pgvector muss den HNSW-Index bei Inserts partiell neu aufbauen, was Latenz kostet.
• Multi-Tenancy mit hunderten isolierten Namespaces: In Pinecone oder Weaviate ist das eine Konfigurationszeile; in pgvector braucht man eigene Schemalogik oder separate Tabellen.

Typisches KMU-Szenario: Was steht wirklich an?

Häufiges Muster: ein Steuerberater mit 15 MA, der seine gesamte Mandanten-Dokumentation (PDF-Bescheide, Verträge, interne Notizen) durchsuchbar machen will. Geschätzte Datenmenge: 50.000 bis 200.000 Dokumente, chunked auf je 300–500 Token. Das ergibt maximal 400.000 Vektoren. Gleichzeitige Nutzer: 15, davon vielleicht 5 gleichzeitig aktiv.

Das ist ein klarer pgvector-Fall. Eine bestehende Managed-Postgres-Instanz bei Supabase oder Railway kostet 20–50 USD/Monat. Die Extension ist mit einem Befehl aktiviert. Der operative Aufwand ist minimal.

Anderes Muster: ein E-Commerce-Händler mit 120 MA, der semantische Produktsuche über 2 Millionen SKUs anbieten will, dazu Echtzeit-Empfehlungen bei 500 gleichzeitigen Seitenaufrufen. Hier reicht pgvector nicht mehr zuverlässig. Der Indexaufbau allein dauert bei dieser Datenmenge Stunden, und die Abfragelatenz steigt unter Last auf mehrere hundert Millisekunden.

Dedizierte Vektordatenbanken: Pinecone, Weaviate, Qdrant

Drei Optionen dominieren aktuell den Markt für spezialisierte Vektordatenbanken:

Pinecone ist Managed-only, kein Self-Hosting. Der Einstieg ist einfach, die API sauber. Kosten: ab ca. 70 USD/Monat für den Starter-Pod, bei ernsthafter Nutzung schnell 300–600 USD/Monat. Für KMU ohne eigene ML-Infrastruktur ist das akzeptabel – solange man die Vendor-Lock-in-Konsequenz bewusst akzeptiert. Pinecone speichert die Vektoren, nicht die ursprünglichen Dokumente; die Metadaten-Filterung ist funktional, aber limitiert gegenüber vollem SQL.

Weaviate bietet Managed Cloud und Self-Hosting. Die integrierte Modularität (eigene Vectorizer-Module, hybride Suche mit BM25) ist stark. Für Teams mit Kubernetes-Erfahrung ist Self-Hosted Weaviate eine ernsthafte Option. Ohne diese Erfahrung ist der operative Aufwand nicht zu unterschätzen.

Qdrant ist aus meiner Sicht die interessanteste Alternative für KMU mit technischen Ressourcen. Open Source, in Rust geschrieben, sehr performant, gutes Rust- und Python-SDK. Self-Hosting ist mit einem einzigen Docker-Container möglich. Qdrant Cloud existiert als Managed-Option ab 0 USD (Free Tier mit 1 GB). Die Filtersyntax ist mächtiger als bei pgvector und die Performance bei 10+ Millionen Vektoren deutlich besser.

Die operative Kostenfrage

Hier wird es konkret. pgvector hat keine Lizenzkosten, aber die Skalierung kostet trotzdem:

• 2 Millionen Vektoren à 1.536 Dimensionen: HNSW-Index ca. 12 GB RAM. Eine Postgres-Instanz mit 16 GB RAM kostet bei AWS RDS ca. 150–200 USD/Monat.
• Bei Pinecone: 2 Millionen Vektoren auf einem p1.x1-Pod kosten ca. 70 USD/Monat – aber ohne SQL-Funktionalität, ohne ACID, mit separater Datenhaltung.
• Bei Qdrant Self-Hosted: Die Infrastrukturkosten entsprechen in etwa pgvector, aber die Vektordatenbank ist auf genau diesen Workload optimiert.

Ein KMU mit bestehendem Datenbankbudget fährt mit pgvector bis zur Grenze günstiger. Wer neu aufbaut und absehbar über 3 Millionen Vektoren kommt, sollte Qdrant von Anfang an einplanen – die Migration von pgvector zu einer dedizierten Lösung kostet später mehr als die initiale Entscheidung.

Hybride Suche: Der oft übersehene Faktor

Ein praktischer Hinweis: Reine Vektorsuche ist selten optimal. In den meisten Dokumenten-Retrieval-Szenarien schlägt hybride Suche – Kombination aus semantischer Ähnlichkeit und Keyword-Matching (BM25/TF-IDF) – die reine Vektorsuche in der Präzision.

pgvector + PostgreSQL Full-Text Search ist eine valide hybride Lösung, erfordert aber eigene Query-Logik für das Ranking (RRF – Reciprocal Rank Fusion). Weaviate hat das eingebaut. Qdrant ebenfalls seit Version 1.7. Pinecone hat es angekündigt, ist aber im Vergleich noch eingeschränkt.

Wer von Anfang an hybride Suche plant, hat mit pgvector mehr Handarbeit – die Flexibilität ist da, aber der Komfort nicht.

Entscheidungsmatrix für die Praxis

Mein Rat

Starten Sie mit pgvector, wenn Postgres bereits im Stack ist. Die Extension ist in zehn Minuten einsatzbereit, die Wartungskosten sind minimal, und für die meisten KMU-Anwendungsfälle reicht die Performance. Messen Sie nach drei bis sechs Monaten Produktivbetrieb: Abfragelatenz unter Last, Indexgröße, gleichzeitige Requests.

Erste Warnsignale, die eine Migration rechtfertigen: Abfragen über 200 ms im Median, RAM-Auslastung über 85 % durch den Vektorindex, oder der Wunsch nach komplexen Metadaten-Filterkombinationen, die in SQL umständlich werden.

Für Neuprojekte mit absehbar großen Datenmengen: Qdrant Self-Hosted auf einer kleinen VM, Qdrant Cloud als Einstieg. Die API ist sauber, die Dokumentation gut, und der Wechsel von pgvector auf Qdrant kostet bei ordentlicher Abstraktion im Code ein Wochenende.

Pinecone ist eine legitime Wahl für Teams, die keinen Infrastrukturaufwand wollen und das Budget haben. Der Lock-in ist real, aber kalkulierbar – solange man weiß, was man tut.

Die teuerste Entscheidung ist nicht die falsche Datenbank. Die teuerste Entscheidung ist, zu früh zu komplex zu bauen – oder zu spät zu merken, dass die Basis nicht trägt.