Pinecone vs. Weaviate vs. Qdrant: Vektor-DB-Vergleich aus DACH/EU-Hosting-Perspektive

Pinecone, Weaviate und Qdrant sind die drei meistgenutzten Vektor-Datenbanken für produktive RAG-Systeme. Aus DACH-B2B-Sicht ist die Auswahl 2026 weniger eine Benchmark- als eine Souveränitäts-Entscheidung: Die Frage, wo die Embeddings liegen, wer darauf zugreifen kann und ob sich der gesamte Stack bei Bedarf on-prem holen lässt, hat rohe QPS- oder Recall-Werte als dominanten Architektur-Filter überholt. Qdrant und Weaviate sind self-hostbar und EU-nativ, Pinecone ist eine US-Managed-SaaS ohne On-Prem-Option.

Die drei Schnellantworten

• Qdrant (Berlin, Apache 2.0): der DACH-native Champion. OSS-Self-Host, Qdrant Cloud in EU-Regionen, Hybrid Cloud (BYO Kubernetes auf STACKIT/Aleph Alpha/Civo) und air-gapped Private Cloud. Souveränitäts-Rating 🟢.
• Weaviate (Amsterdam, BSD-3): die EU-native Alternative mit reifem Hybrid-Search und Modul-Ökosystem. Self-Host, Weaviate Cloud (inkl. EU), Embedded. Souveränitäts-Rating 🟢.
• Pinecone (US, proprietär): Managed-only-SaaS, EU-Regionen vorhanden (eu-west-1 GCP, AWS Frankfurt), aber kein Self-Host, kein On-Prem. Souveränitäts-Rating 🟠 - nur mit vertraglicher Exit-Klausel für nicht-sensible Workloads.

Warum Hosting-Souveränität der erste Filter ist

Für jeden DACH-Deployer zwischen 200 und 50.000 FTE, der RAG über deutschsprachige Inhalte betreibt, ist das EU-US-Datentransfer-Regime nicht stabil. Das 2023 in Kraft getretene EU-US Data Privacy Framework ist aktiv beklagt; eine realistische Invalidierungs-Wahrscheinlichkeit für eine nächste „Schrems III"-Entscheidung liegt laut Research im Fenster 2026-2028. Beschaffungs- und Architektur-Teams formulieren deshalb zunehmend die „sovereign-deployable als vertragliche Exit-Klausel": Wird ein US-Managed-Dienst rechtlich untragbar, muss der Stack innerhalb von typischerweise 3-6 Monaten auf souveräne Infrastruktur umgezogen werden können.

Genau hier trennt sich das Feld. Der entscheidende Primär-Filter ist das Deployment-Modell: Kann eine Lösung on-prem oder in einer souveränen DACH-Cloud (STACKIT, IONOS, OTC, plusserver, Hetzner, OVHcloud) laufen? Open-Source-Engines wie Qdrant und Weaviate machen die Exit-Portabilität konkret statt nur aspirational. Pinecone als proprietäre SaaS bietet diese Portabilität strukturell nicht - das ist kein Qualitätsurteil über das Produkt, sondern eine Beschaffungs-Realität für regulierte Branchen.

Direktvergleich: Pinecone vs. Weaviate vs. Qdrant

Alle Angaben Stand 2026 und auf Basis der Research-Quelle.

Performance und Skalierung - ehrliche Zahlen

Reproduzierbare 2025-2026-Benchmarks (VectorDBBench, ann-benchmarks-Forks, unabhängige Harnesses) zeichnen ein konsistentes Bild: Qdrant und Weaviate liegen auf glatten HNSW-Recall-Latenz-Kurven mit starker Filter-Performance. Qdrant ist komfortabel bei 100M Vektoren pro Cluster; Produktions-Referenzen umfassen Bosch und Tripadvisor im Bereich hunderter Millionen bis niedriger Milliarden mit Sharding. Die GPU-beschleunigte Indizierung (eingeführt Januar 2025) verkürzt Build-Zeiten. Weaviate skaliert mit Sharding ebenfalls auf 100M+ Vektoren; das Modul-Ökosystem (Hybrid, generative Module, Multi-Tenancy) ist reif.

Latenzprofile für 1024-dim, 10M Vektoren auf Commodity-Hardware: HNSW in-memory Top-10 unter 10 ms end-to-end auf Qdrant, Weaviate oder pgvector mit passendem ef_search. Hybrid plus Cross-Encoder-Reranker landet bei 150-500 ms - der Reranker ist dabei der latenz-elastische Teil und das erste, was bei harten Sub-100-ms-SLAs entfällt.

Zur Einordnung der relativen Größenordnung nennt die Research einen veröffentlichten Benchmark (Hersteller-Daten, aber in der Ordnung über unabhängige Läufe konsistent): bei 50M Vektoren und 99 % Recall lag Qdrant bei 41 QPS gegenüber pgvectorscale (StreamingDiskANN in Postgres) bei 471 QPS. Die Lehre daraus ist nicht „Qdrant ist langsam", sondern: Für viele DACH-Mittelstands-Projekte unter ~50M Vektoren ist pgvector/pgvectorscale auf managed Postgres oft die betrieblich einfachere und souveränere Wahl - eine Datenbank, eine Backup-Story, eine DSGVO-AVV-Kette.

DSGVO-Eignung und Lösch-Semantik

Ein wichtiger Hinweis vorab: Dies ist keine Rechtsberatung. Die folgenden Punkte fassen die Research zusammen; die konkrete DSGVO-Bewertung muss pro Anwendungsfall mit Fachjurist:innen erfolgen.

Embeddings, die aus personenbezogenen Daten abgeleitet werden, gelten laut EDPB Opinion 28/2024 und Guidelines 01/2025 mit hoher Wahrscheinlichkeit selbst als personenbezogen - eine fallweise Re-Identifikations-Risikobewertung ist erforderlich. Das CJEU-Urteil C-413/23 P (SRB v EDPS, September 2025) präzisiert, dass pseudonymisierte Daten nicht automatisch für jeden Empfänger personenbezogen sind - das verengt die Pflichten, hebt sie aber nicht auf.

Für die Vektor-DB-Auswahl folgen daraus zwei harte Beschaffungs-Gates:

• Cross-Border-Transfer: Ein Embedding einer Mitarbeiter-E-Mail in einer US-gehosteten Vektor-DB ist ein Drittland-Transfer. Das betrifft Pinecone direkt; Qdrant und Weaviate können vollständig in DACH-souveräner Infrastruktur betrieben werden.
• Right-to-Erasure (Art. 17): Embeddings müssen löschbar sein. Technisch nicht-trivial, da HNSW-Graphen keine effiziente Punkt-Löschung unterstützen. Vendor-spezifisch: pgvector-Löschungen sind effizient (Postgres MVCC), Qdrant unterstützt effiziente Point-Deletes, Milvus arbeitet mit Tombstones plus Compaction. Die Lösch-Semantik vor Vertragsabschluss zu verifizieren ist ein hartes Gate.

Ecosystem-Integration

Auf API-Ebene ist die Vektor-DB-Schicht 2026 weitgehend commoditisiert: HNSW ist überall, Hybrid-Search ist table-stakes. Alle drei Datenbanken verfügen über ausgereifte offizielle Integrationen in LangChain/LangGraph und LlamaIndex sowie MCP-Anbindung. Die echte Differenzierung liegt nicht mehr in der Integration, sondern in (a) Souveränitäts-Posture und Deploybarkeit, (b) Hybrid-Search- und Reranker-Qualität auf Deutsch mit Komposita und Fachsprache, (c) multimodaler Dokument-Bild-Unterstützung (ColPali) und (d) operativer Reife im Bereich 10M-100M+ Vektoren. Bei (c) ist Qdrant mit nativem Multi-Vektor/Late-Interaction den anderen beiden voraus; Weaviate ist hier experimentell.

Entscheidungsmatrix nach Szenario

Konkretes Beispiel: Mittelstands-RAG mit Kostenrahmen

Ein DACH-Mittelständler (ca. 800 FTE) baut RAG über deutsche PDF-, Office- und SharePoint-Inhalte, ~8M Chunks. Empfohlener Stack laut Research-Blueprint „VEC-Mittelstand": pgvector 0.8+ mit pgvectorscale auf managed Postgres bei IONOS oder STACKIT; BM25 via ParadeDB pg_search; Embeddings mit BGE-M3 (MIT) oder Jina v4 (Apache 2.0, Berlin) self-hostet auf einer einzelnen L4-/A10G-GPU; Reranker BGE Reranker M3 (MIT) auf derselben Instanz. Speicher-Faustregel für 10M Vektoren bei 1024 dim, float32 HNSW: ~40 GB roh plus 50-100 % Index-Overhead; mit halfvec ~30-40 GB, mit SQ8 ~10-20 GB. Time-to-ROI für den ersten produktiven Use Case 3-6 Monate, Budget-Rahmen Jahr 1 €30k-€150k. Erst wenn pgvector ein reales Scale-Ceiling erreicht (>50M Vektoren), lohnt der Wechsel auf eine dedizierte Vektor-DB - die meisten Mittelstands-Use-Cases überschreiten 5-20M Vektoren nie.

Für Agenturen und B2B-Entscheider

Wer als Agentur multi-tenant aufbaut, sollte explizit tiern: pgvector-Tier für SMB, Qdrant-Tier für Mittelstand, Qdrant-on-customer-K8s für Konzerne. Per-Tenant-Isolation (Schema oder Row-Level-Security in Postgres, Collection-per-Tenant in Qdrant, per-Tenant-KMS-Keys) ist Pflicht - eine geteilte Collection mit Metadaten-Filter ist ein DSGVO-Unfall im Wartezustand. Für DACH-B2B-Entscheider gilt: „EU-Region verfügbar" ist nicht gleich Souveränität. Verifiziere CLOUD-Act-/FISA-702-Exposure, Sub-Processor-Disclosure, No-Training-on-Data, Lösch-Semantik und vertragliche Exit-Klauseln. Blck Alpaca begleitet die souveränitäts-klassifizierte Auswahl und Implementierung des Vektor-DB- und Embedding-Stacks für DACH-Organisationen - von der pgvector-Mittelstandslösung bis zur Qdrant-Hybrid-Cloud-Architektur für regulierte Workloads.