Vektor-Datenbanken im Vergleich: Qdrant, Weaviate, Milvus, Pinecone, Chroma, pgvector

Was ist eine Vektor-Datenbank?

Eine Vektor-Datenbank speichert Embeddings (Zahlenlisten mit 384 bis 3072 Dimensionen) und beantwortet eine zentrale Frage in Millisekunden: Welche k Vektoren im Bestand sind dem Anfrage-Vektor am ähnlichsten? Klassische relationale Systeme können das auch – aber nicht effizient. Bei 1 Million Vektoren wäre ein Brute-Force-Vergleich rechenintensiv; eine spezialisierte Vektor-DB erledigt dieselbe Suche dank Approximate Nearest Neighbor (ANN) Indexes in unter 20 Millisekunden.

Die Wahl der Vektor-DB ist eine der wenigen technischen Entscheidungen, die ein KMU-Mandant beim AI-Audit aktiv treffen sollte. Sie bestimmt den Datenort (lokal in Falkenstein oder gehostet in den USA), die Betriebskosten (selbst betreiben oder Managed Service) und die Filter-Fähigkeiten (kann ich nach Mandant, Datum oder Vertraulichkeitsstufe einschränken?).

Im Mai 2026 existieren sechs ernsthafte Optionen. Drei sind self-hosted-first (Qdrant, Weaviate, Milvus), eine ist hosted-first (Pinecone), eine ist eingebettet-first (Chroma), eine ist eine PostgreSQL-Erweiterung (pgvector). Die anderen Spieler (Vespa, Vald, Marqo) sind entweder Nische oder zu spezialisiert für KMU-Setups.

Warum es wichtig ist

Drei Achsen entscheiden über Eignung: Datenresidenz, Latenz vs. Recall, Filter-Komplexität. Wer die falsche DB wählt, bezahlt mit Migration später – eine Migration zwischen Vektor-DBs ist kein triviales Re-Indexing, sondern eine Pipeline-Neubau-Übung.

Datenresidenz: Für revDSG-strenge Mandanten (Steuerakten, Mandats-Korrespondenz unter StGB Art. 321) gilt: Vektoren enthalten Wissen aus den Originaldokumenten. Der MIT-Forschungsstand 2024 (Morris et al.) zeigt, dass Embeddings unter Umständen teilweise rekonstruierbar sind. Wer also Anwalts- oder Treuhand-Daten in einer US-gehosteten Vektor-DB ablegt, hat ein Drittlandtransfer-Problem.

Latenz vs. Recall: HNSW-Indexes (Hierarchical Navigable Small World) liefern höchsten Recall bei moderater Latenz und sind heute Industriestandard. IVF-Indexes (Inverted File) sind schneller bei sehr grossen Beständen, kosten aber Recall. Für typische KMU-Setups (< 10 Millionen Vektoren) ist HNSW die richtige Wahl.

Filter: „Finde mir die fünf ähnlichsten Dokumente zu dieser Frage, aber nur für Mandant X und nach 2024-01-01" – das ist filterte Vektorsuche. Qdrant, Weaviate, Milvus und Pinecone können das nativ. Chroma kann es eingeschränkt. pgvector kann es perfekt – weil es eben Postgres ist.

Die sechs Optionen im Detail

Qdrant (Rust, open-source, gehostet als Qdrant Cloud verfügbar): läuft auf einem Hetzner-Server mit 4 vCPU und 8 GB RAM problemlos für Millionen Vektoren. Beste Filter-Performance unter den Spezialisten dank Payload-Index. Scalar- und Binary-Quantisierung für kompakten Speicher. Ist unsere Standard-Wahl für Schweizer KMU mit revDSG-Anspruch.

Weaviate (Go, open-source, Cloud verfügbar): hat eine eigene GraphQL-API und integriert Embedding-Modelle direkt – man kann Rohtexte einliefern und Weaviate erzeugt die Vektoren. Bequem für Prototyping, aber die Abstraktionsebene ist hoch. Module-System für Reranking und Generative-Tasks eingebaut.

Milvus (Go/C++, open-source, Zilliz Cloud): die schwerste Lösung der Gruppe – gemacht für sehr grosse Bestände (Milliarden Vektoren). Distributed-Architecture, mehrere Index-Typen (HNSW, IVF, DiskANN). Overkill für KMU, richtig für Enterprise mit dedizierten DBA.

Pinecone (proprietär, nur gehostet, USA): einfachste Inbetriebnahme – keine Server, keine Updates, nur API. Filter und Metadaten gut. Nachteil: Daten liegen in US-Regionen, monatliche Kosten ab ~80 USD für kleine Setups, kein Self-Hosting möglich. Für CH-Daten mit Berufsgeheimnis ungeeignet.

Chroma (Python, open-source, eingebettet): läuft inprocess in der Python-Anwendung oder als kleiner Server. Sehr einfach, für Prototypen und kleine Bestände (< 1 Million Vektoren) ideal. Skaliert schlecht bei Production-Last und filtert weniger flexibel als Qdrant.

pgvector (PostgreSQL-Erweiterung, open-source): Vektoren als zusätzliche Spalte in der Postgres-Tabelle. HNSW-Index seit Version 0.5.0, halbway-State of the Art. Idealer Einstieg, wenn Postgres ohnehin läuft – keine zusätzliche Infrastruktur. Bei sehr grossen Beständen (>10M Vektoren) oder hohen Concurrent-Query-Lasten weniger optimiert als spezialisierte DBs.

Auswahl-Workflow in 6 Schritten

1. 01Datenresidenz klären: müssen Vektoren in CH/EU bleiben? Wenn ja, Pinecone raus.
2. 02Volumen schätzen: Anzahl Dokumente × durchschnittliche Chunks pro Dokument. < 1M → pgvector/Chroma, 1–10M → Qdrant, > 10M → Milvus/Qdrant-cluster.
3. 03Filter-Anforderungen listen: Welche Metadaten (Mandant, Datum, Vertraulichkeit) müssen filterbar sein? Qdrant/Weaviate/pgvector können alles, Chroma weniger.
4. 04Latenz-Budget definieren: P95 < 100 ms? Spezialisierte DB (Qdrant, Pinecone). P95 < 500 ms reicht? pgvector ist OK.
5. 05Operations-Modell wählen: Self-host (Qdrant, pgvector) vs. Managed (Pinecone, Qdrant Cloud, Weaviate Cloud). Self-host braucht 0.5–2 Tage Setup + monatliche Wartung.
6. 06PoC mit echten Daten: 5.000–10.000 Dokumente einliefern, 30 echte Beispiel-Queries laufen lassen, Recall@5 und P95-Latenz messen. Erst dann produktiv ausrollen.

Empfehlung je Anwendungsfall

CH-Treuhand mit < 1M Vektoren, revDSG-streng, Postgres läuft bereits: pgvector. Kein neuer Service, dieselben Backups, dasselbe Monitoring. Mit HNSW-Index reicht Postgres bis ungefähr 5–10 Millionen Vektoren – danach lohnt der Wechsel.

CH-Treuhand/Anwalt mit 1M–10M Vektoren, revDSG-streng: Qdrant on-prem auf Hetzner Falkenstein/Helsinki. Beste Filter, beste Quantisierung, gute Docs. Standard-Empfehlung.

KMU mit > 10M Vektoren oder hohe Concurrent-Last: Milvus oder Qdrant (cluster-mode). Beide skalieren in den Milliarden-Bereich. Milvus mehr Tools, Qdrant einfacher zu betreiben.

Prototyp/PoC, < 100k Vektoren: Chroma oder pgvector. Schnelles Aufsetzen, kein DevOps. Bei Erfolg auf Qdrant migrieren.

Hosted-only-Setup, keine eigenen Server, US-Daten OK: Pinecone. Wenn die Daten nicht unter Berufsgeheimnis stehen und der Compliance-Pfad mit US-Hosting passt (Datentransfer-Impact-Assessment liegt vor), ist Pinecone die bequemste Wahl.

Wann eine Vektor-DB falsch ist

Wenn Sie weniger als ungefähr 5.000 Dokumente haben und keine Latenz-Anforderung unter einer Sekunde, ist eine Vektor-DB überzogen. In-memory Lösungen mit FAISS oder annoy in Python tun es. Auch wenn die Suche tatsächlich nur Stichwörter braucht (Belegnummer, Mandantenname, Datum), gehört das in eine relationale Datenbank, nicht in einen Vektor-Index – schneller, billiger, exakter.

Wenn Sie Embeddings mit OpenAI text-embedding-3-large mit 3072 Dimensionen abspeichern wollen und mehr als 100 Millionen Stück erwartet werden, müssen Sie schon vor der Auswahl rechnen: das sind 1.2 TB Roh-Daten ohne Index – Pinecone, Qdrant und Milvus skalieren das, aber die Hosting-Kosten werden relevant. In so einem Fall ist Quantisierung (binary oder scalar) nicht optional, sondern Pflicht – und das engt die Auswahl ein.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. ANN-Benchmarks – community vector-search benchmark · 2026-04
2. Qdrant Documentation – Vector Search Engine · 2026-05
3. pgvector – Open-Source Postgres extension (HNSW since 0.5.0) · 2026-03
4. Milvus Documentation – distributed vector DB · 2026-04
5. Morris et al., Text Embeddings Reveal (Almost) As Much As Text (EMNLP 2023) · 2023-10