Vector-DB-Rechner: Pinecone vs Weaviate vs Qdrant vs pgvector

Wann pgvector reicht — Production-Spoiler: meistens

Der häufigste Fehler, den Teams beim ersten RAG-Setup machen: sie schmeißen Pinecone drauf, weil Pinecone in jedem Twitter-Thread auftaucht. Dabei laufen 80 % aller Production-RAG-Workloads mit unter 1 M Vectors. Bei dieser Größe ist pgvector — die Postgres-Extension, die einen HNSW-Index pro Spalte legt — fast immer ausreichend. Du hast dieselbe DB für deine App-Daten und für die Embeddings. Du kannst in einem SQL-JOIN aus User-Tabelle und Vector-Suche kombinieren — etwas, das mit externem Pinecone zwei API-Calls und eine Sync-Pipeline kostet.

Die Grenze: HNSW-Index-Builds in pgvector dauern bei 10 M Vectors mit 1024 dim 30-60 Minuten und blockieren während dieser Zeit das Schreiben. Updates auf bestehende Vectors triggern partielle Re-Builds. Für Use-Cases mit häufigen Updates (z. B. Knowledge-Base, die wöchentlich re-indexed wird) wird pgvector unhandlich. Bis zu 5 M Vectors mit eher Read-heavy Workload: keine Bedenken.

Was du nicht bekommst: Sub-50ms-Latenzen bei 50 M+ Vectors. Distributed Multi-Region-Setups. Wenn du eine konsumentennahe Search-App baust (Algolia-Ersatz für Produkt-Search), kommt irgendwann ein Pinecone- oder Qdrant-Move. Aber selbst dann ist der Switch-Path easy — alle ernstzunehmenden Vector-DBs sprechen REST oder gRPC, und die meisten Frameworks (LangChain, LlamaIndex) haben swap-bare Adapter.

Pinecone Serverless vs Pod — wann der Wechsel sich rechnet

Pinecone hat 2024/2025 sein Serverless-Modell deutlich verbessert. Du zahlst $0,33 pro Million Write-Units, $1,10 pro Million Read-Units und $0,33 pro GB-Monat Storage. Klingt günstig — und ist es für viele Hobby- und Mittelschicht-Workloads. Ab einer bestimmten Größe kippt die Rechnung aber: ein einziger fixed Pod (p1.x1 oder s1.x1) kostet ~70 USD/Monat unabhängig vom Traffic. Bei 10 M Reads pro Tag — also 300 M pro Monat — zahlst du auf Serverless rund 330 USD nur für Reads. Ein s1-Pod macht das fix für 70 USD ohne extra Read-Charges.

Faustregel: sobald deine monatliche Serverless-Rechnung über 150-200 USD geht, wechselst du zu Pods. Sub-Faustregel: für planbare Workloads mit konstantem Traffic sind Pods sowieso ehrlicher kalkulierbar — du hast keinen versteckten Cost-Spike bei einer viral gegangenen Marketing-Aktion. Für Sandbox-Workloads, Spikes und neue Features ist Serverless der bessere Start.

Was du bei Pods aufgibst: Multi-Tenancy. Ein Pod ist ein Index. Wenn du eine B2B-SaaS mit 5.000 Kunden baust und jeder Kunde sein eigenes RAG braucht, ist Serverless mit Namespaces der einzige sinnvolle Weg — oder du wechselst zu Qdrant Cloud, das Multi-Tenancy von Grund auf eingebaut hat.

Self-Hosting auf Hetzner — die echten Stundenkosten

Auf Twitter und in Indie-Hacker-Threads wirst du oft lesen: „Hetzner CCX13 für 20 EUR, da läuft Qdrant drauf, spar dir 200 EUR Pinecone". Das ist halb richtig. Die VM kostet wirklich nur 20 EUR im Monat. Was niemand mit-kalkuliert: die Stunden, die du investierst. Realistisch sind es 2 Stunden pro Woche, sobald die Box wirklich Production-Traffic sieht — Sicherheits-Updates, Backup-Checks, gelegentliche OOM-Alerts, das Drama mit dem ersten Disk-Full-Event.

Bei einem Marktstundensatz von 80 EUR für deine Zeit (oder die deines Engineers in DE) sind 2 h/Woche × 4.33 Wochen = etwa 700 EUR/Monat versteckte Ops-Kosten. Bei dieser Rechnung gewinnt Self-Host nur, wenn:

• du in einem Team bist, das ohnehin Postgres oder Redis selbst betreibt — die Vector-DB ist dann marginal-cost und die Ops-Stunden verteilen sich,
• du a) als Solo-Founder ohne Ops-Stundenkosten arbeitest (deine Zeit ist „kostenlos"), oder b) das Lernen wert ist — also du sowieso tiefere Vector-DB-Internals verstehen willst,
• die Workload-Größe einen Managed-Provider deutlich teurer macht (10 M+ Vectors mit Production-Traffic auf Pinecone Pods läuft schnell auf 300+ USD/Monat — da gewinnt Hetzner auch mit 700 EUR Ops-Kosten).

Der Rechner oben hat einen Slider für deinen Ops-Stundensatz. Stell ihn auf 0, wenn du Solo-Founder bist und deine Zeit nicht opportunistisch verbuchst. Stell ihn auf 80-120 EUR, wenn du ehrlich kalkulierst und dein Engineer die Zeit auch produktiv im Core-Produkt verbringen könnte.

Multi-Tenancy: was nur Pinecone und Qdrant richtig können

Multi-Tenant-Vector-Search ist eines dieser Themen, die im Sandbox harmlos aussehen und in Production zu Schmerzen werden. Das Problem: du hast 1.000 Kunden, jeder Kunde hat 10.000 Dokumente, du willst beim Suchen filtern nach Kunde — oder besser: gar nicht erst kreuz-suchen. Wer das mit einer einzigen großen Index-Tabelle macht und über WHERE tenant_id filtert, lässt den HNSW-Index halb ungenutzt — die Filter werden post-search angewendet, und du holst für jede Query mehr Vectors als nötig.

Pinecone Namespaces sind die saubere Lösung: jeder Tenant kriegt seinen eigenen logischen Index innerhalb derselben physikalischen Pinecone-Region. Du kannst Millionen Namespaces erstellen, ohne extra zu zahlen. Bei Reads filterst du per Namespace in der API-Call selbst — der Index sucht nur in den passenden Vectors.

Qdrant Collections machen dasselbe etwas explizit anders: du hast Sharding pro Collection. Bei vielen kleinen Tenants mit wenig Daten ist das günstiger als Weaviate, das pro Tenant einen eigenen Shard hat (also einen Storage-Overhead pro Tenant). pgvector löst es mit einer einfachen tenant_id-Spalte und einem Composite-Index — funktioniert, aber wird inefficient bei stark unbalanced Tenants (ein Kunde hat 1 M Vectors, alle anderen unter 1.000 — der Index ist dann für die kleinen Tenants verschwenderisch).

Häufige Fragen