Vector Databases erklärt — Pinecone, Qdrant, Weaviate, pgvector im Vergleich 2026

Vector DBs sind 2026 commoditized — die Auswahl ist wichtig, aber nicht mehr differenzierend. Drei Jahre nach dem RAG-Hype von 2023 hat sich das Feld konsolidiert: Pinecone als Managed-Platzhirsch, Qdrant als Self-Hosted-Powerhouse, Weaviate als feature-reiche Mid-Tier, pgvector als "Postgres kann das auch"-Sieger. Wer 2026 ein RAG-System baut und sich monatelang in Vector-DB-Benchmarks verliert, optimiert die falsche Stelle — die echten Gewinne liegen bei Retrieval-Qualität, Chunking und Reranking.

1. Was eine Vector DB überhaupt anders macht

Kurze Auffrischung — was unterscheidet eine Vector DB von einem normalen Postgres-Index? Drei Dinge:

• Approximate Nearest Neighbor (ANN) Search: statt exakt zu vergleichen, finden ANN-Algorithmen (HNSW, IVF, Annoy) die nächsten Vektoren mit hoher Wahrscheinlichkeit in O(log n) statt O(n). Für 100M+ Vektoren zwingend, für 1M Vektoren oft Overkill.
• Optimierte Storage für Float-Vektoren: Quantization, Compression (Product Quantization, Scalar Quantization), Memory-Mapped-Files. Bei großen Setups Faktor 5–10 weniger RAM-Bedarf.
• Hybrid-Search: Kombination aus Dense-Vector-Search (Semantik) und Sparse/Lexical-Search (BM25, Keywords). 2026 in fast jedem Production-RAG-Setup zwingend, weil reine Vector-Search bei Eigennamen, Codes und exakten Phrasen schwächelt.

Wichtig: pgvector kann seit Version 0.7 (Mai 2024) HNSW und seit Version 0.8 (Q3 2025) auch Quantization. Der historische Performance-Gap zu spezialisierten DBs ist 2026 für die meisten Mittelstands-Use-Cases weitgehend geschlossen.

2. Dimension 1 — Hosting: Managed vs Self-Hosted

Pinecone ist 2026 weiterhin Managed-Only. Wer DSGVO-strenge Setups oder On-Premises-Anforderungen hat, fällt damit raus. Pinecone bietet EU-Regionen (Frankfurt, Dublin), aber wer "data stays on our metal" braucht, muss zu Qdrant, Weaviate oder pgvector.

Qdrant ist 2026 die nach unserer Erfahrung sauberste Self-Hosted-Option. Docker-Compose oder Helm-Chart, im Cluster-Setup auch problemlos auf Kubernetes. Operativ deutlich pflegeleichter als Weaviate.

pgvector ist nur dann "kein Aufwand", wenn ihr Postgres ohnehin betreibt. Mit AWS RDS, GCP Cloud SQL oder einem self-hosted Postgres- Cluster bekommt ihr pgvector gratis dazu.

3. Dimension 2 — Performance bei skaliertem Setup

Konkrete Zahlen aus unseren Benchmarks (Q2 2026, 1536-dim Embeddings, HNSW-Index, ef_search=128):

• 1M Vektoren, single-node: alle vier liefern Sub-50ms-p95-Latenz. pgvector ist 5–15 ms langsamer, was irrelevant ist.
• 10M Vektoren, single-node: Qdrant und Pinecone führen mit p95 ~60ms, Weaviate ~80ms, pgvector ~90ms. Immer noch alle gut.
• 100M+ Vektoren, sharded: hier wird's spannend. Qdrant und Pinecone skalieren am saubersten, Weaviate's Cluster-Mode hat Stand Q1 2026 noch Rough Edges, pgvector wird ab ~50M Vektoren operativ schwer (Index-Building dauert lange, Replication wird tricky).

Praktische Faustregel für 2026: unter 10M Vektoren ist die Wahl irrelevant für Performance. Zwischen 10M und 100M wird die spezialisierte DB relevant. Über 100M ist Qdrant oder Pinecone Default.

4. Dimension 3 — Hybrid Search (Dense + Sparse + Lexical)

Hier ist 2026 der größte echte Differenzierer.

• Weaviate hat Hybrid-Search seit Version 1.18 (2023) eingebaut, mit konfigurierbarer BM25-Sparse-Komponente und Dense-Vector-Komponente. Default-Alpha-Werte sind brauchbar out-of-the-box.
• Qdrant unterstützt seit Version 1.10 (Mitte 2024) Sparse Vectors, also auch BM25 oder SPLADE als zweite Komponente. Erfordert etwas mehr Setup als Weaviate, ist aber flexibler.
• Pinecone hat Hybrid-Search seit 2024 in der Serverless-Architektur. Funktioniert solide, ist API-seitig minimal umständlich.
• pgvector kombiniert mit Postgres-Volltextsuche (tsvector / ts_rank) — geht, ist aber Manual Plumbing. Es gibt seit 2025 Extensions wie pg_search (basierend auf Tantivy/Lucene), die BM25 in Postgres ordentlich machen.

Faustregel: wenn Hybrid-Search von Tag 1 wichtig ist (z.B. Dokumenten-Suche mit Eigennamen, Code-Search, Produktkataloge), ist Weaviate die schnellste Strecke. Mit Qdrant + Sparse-Vectors hat man mehr Flexibilität, aber 2–3 Tage Setup-Mehraufwand.

5. Dimension 4 — Permissions und Multi-Tenant

In B2B-SaaS-Setups, wo jeder Kunde nur seine eigenen Daten sehen darf, trennt sich die Spreu vom Weizen.

• Qdrant hat seit Version 1.8 Payload-Filter-Indexing und seit 1.11 echte Multi-Tenant-Collections mit per-Tenant-Quotas. 2026 die ausgereifteste Multi-Tenant-Story der spezialisierten DBs.
• Weaviate hat Multi-Tenancy seit Version 1.20 (2023), funktioniert, ist aber operativ etwas komplexer als Qdrant.
• Pinecone hat "Namespaces" pro Index — funktioniert, aber das Permissions-Modell ist auf API-Key-Ebene, nicht pro Tenant. Für strikte Tenant-Isolation braucht ihr eine Application-Layer-Logik.
• pgvector profitiert hier vom Postgres-RLS (Row-Level Security) — echte Tenant-Isolation auf DB-Ebene, mit allen Postgres-Permissions- Mechanismen. Für viele Setups die sicherste Option.

Für regulierte Branchen (Finanzdienstleister, Gesundheitswesen) mit DSGVO-konformer Multi-Tenant-Pflicht ist pgvector + Postgres-RLS oft der saubere Weg — und ein nicht-triviales Argument.

6. Dimension 5 — Kosten 2026

Realistische Größenordnungen für ein RAG-System mit ~10M Vektoren, 1536-dim, moderater Query-Load (~50 QPS p95):

• Pinecone Standard, EU-Region: $70–120/Monat für 10M Vektoren plus Query-Kosten, je nach Pod-Type. Für 100GB Vektoren rechnet ihr mit $600–1200/Monat.
• Qdrant Cloud (EU): $40–80/Monat für vergleichbare 10M, je nach Replikation.
• Qdrant Self-Hosted auf einem Hetzner-Dedicated (€60–120/Monat) für 10M Vektoren völlig ausreichend.
• Weaviate Cloud: $50–100/Monat für 10M Vektoren.
• pgvector in eurem bestehenden Postgres: marginale Zusatzkosten — nur das RAM und Disk, das die Vektoren brauchen. Typisch +€20–40/Monat RAM-Aufschlag.

Bei skalierten Setups (>50M Vektoren, hohe QPS) konvergieren die Kosten zwischen den spezialisierten DBs. Pinecone bleibt am oberen Ende, Self-Hosted-Qdrant am unteren.

7. Wann welche DB konkret

Pragmatische Entscheidungsmatrix, die wir in Audits nutzen:

• Start-Greenfield, Postgres ist eh da: pgvector. Punkt.
• Production-Setup <10M Vektoren, ohne Postgres: Qdrant Self-Hosted oder Cloud.
• Hybrid-Search ist Tag-1-Anforderung: Weaviate oder Qdrant mit Sparse-Vectors.
• Kein Ops-Team, Budget kein Thema: Pinecone Managed.
• Strikte DSGVO-Multi-Tenant-Anforderung mit On-Premises: pgvector mit RLS oder Qdrant Self-Hosted.
• Über 50M Vektoren, hohe QPS: Qdrant Cluster oder Pinecone, je nach Ops-Kapazität.

8. Was wirklich differenziert (Spoiler: nicht die Vector DB)

Aus 20+ RAG-Projekten 2024–2026 ist die Lektion eindeutig: der größte Hebel für Retrieval-Qualität sind nicht Vector-DB-Features, sondern:

1. Chunking-Strategie (Größe, Overlap, Hierarchie)
2. Embedding-Modell (jina-v3, voyage-3, openai-text-embedding-3-large 2026 die Top-3 für Deutsch)
3. Reranking mit Cross-Encoder (Cohere Rerank 3, BGE-Reranker)
4. Query-Rewriting mit LLM vor dem Retrieval
5. Hybrid-Search (siehe oben)

Wer einen halben Tag in jede dieser fünf Stellen investiert, gewinnt mehr Retrieval-Qualität als durch jeden Vector-DB-Wechsel. Wir sehen 2026 immer wieder Teams, die wochenlang Pinecone gegen Qdrant benchmarken — und dabei mit BGE-base statt voyage-3 embedden. Das ist Optimierung am falschen Ende.

Was als Nächstes?

Für die nächsten 30 Tage: wenn ihr ein RAG-System plant, fangt mit pgvector an — vorausgesetzt, ihr habt schon Postgres. Wenn nicht, ist Qdrant Self-Hosted der Default. Wenn ihr Hybrid-Search von Tag 1 braucht, ist Weaviate eine ehrliche Option. Investiert das gesparte Vector-DB- Evaluations-Wochenende lieber in ein gutes Embedding-Modell, sauberes Chunking und einen Reranker — dort liegen die echten Quality-Gewinne. Wenn ihr beim RAG-Architektur-Setup Sparring braucht: ein 30-Minuten-Discovery-Call kostet nichts und spart oft einige Wochen Tool-Vergleich.