Vektor-Datenbanken im Vergleich: 10 Optionen für RAG, Suche und Empfehlung

Was eine Vektor-Datenbank ist

Eine Vektor-Datenbank speichert hochdimensionale Embedding-Vektoren – typisch 384 bis 3072 Dimensionen pro Eintrag – und findet zu einem Such-Vektor in Millisekunden die nächsten Nachbarn. Diese Nächster-Nachbar-Suche (approximate nearest neighbour, ANN) ist die Basis für Retrieval-Augmented Generation, für semantische Suche, für Empfehlungs-Systeme und für Anomalie-Erkennung. Eine relationale Datenbank kann diese Aufgabe theoretisch lösen, kommt aber bei mehr als ein paar tausend Einträgen ohne spezialisierten Index nicht mehr unter eine Sekunde Antwortzeit.

Stand Mai 2026 stehen rund zwei Dutzend produktive Vektor-Datenbanken zur Verfügung. Diese Seite vergleicht die zehn Optionen, die in KMU- und Treuhand-Kontexten am häufigsten auftauchen: Qdrant, Weaviate, Milvus, Chroma, pgvector, Pinecone, Redis (mit RediSearch), Vespa, LanceDB und Elasticsearch mit kNN. Alle zehn beherrschen ANN-Suche mit HNSW oder vergleichbaren Indexstrukturen; die Unterschiede liegen in Lizenz, Hosting-Modell, Filter-Mächtigkeit, EU-Fähigkeit und in der Integration mit bestehenden Stacks.

Die zentrale Auswahl-Frage in der Schweiz lautet selten „welche Datenbank ist am schnellsten". Sie lautet: welche Datenbank passt zur bestehenden Infrastruktur, zur Datenschutz-Anforderung und zum Team-Wissen. Eine Postgres-DB, die bereits läuft, beantwortet die Frage anders als ein leeres Datacenter mit Kubernetes-Kompetenz.

Warum die Wahl wichtig ist

Die Vektor-Datenbank ist eines der wenigen Stack-Elemente, das nach der Auswahl schwer zu tauschen ist. Embeddings, Payload-Schema, Filter-Indexe und Ingestion-Pipeline werden auf die gewählte Plattform optimiert. Ein Wechsel ist machbar – eine Migration von 1 Mio. Vektoren dauert typisch einen halben Tag – aber er bricht die produktive Pipeline und erzwingt Re-Tests aller RAG-Antworten.

Drei Konsequenzen treffen besonders KMU-Setups. Erstens Lizenz: pgvector und Qdrant sind Apache-2.0 oder PostgreSQL-Lizenz, sodass eigene Forks und kommerzielle Embedded-Nutzung problemlos sind. Elasticsearch hat seit 2021 die Elastic License v2 / SSPL – für Self-Hosting in einer Anwaltskanzlei oder Treuhand ist das nutzbar, für ein SaaS-Produkt auf Basis von Elasticsearch nicht. Pinecone ist proprietär ohne Self-Host-Option; ein Wechsel zwingt zur Migration.

Zweitens Hosting: nur Self-Host-Optionen geben in der Schweiz die volle Kontrolle über den Datenstandort. Pinecone bietet eine EU-Region (eu-west-1), bleibt aber US-Unternehmen – für Mandantendaten unter revDSG ist das ein Transfer-Impact-Assessment wert. Qdrant, Weaviate, Milvus, pgvector, Vespa, Redis und LanceDB laufen alle auf Hetzner Helsinki oder Falkenstein.

Drittens Filter: payload-indexierte Filter sind der Unterschied zwischen „Treffer in 50 ms" und „Treffer in 2 Sekunden". Qdrant und Weaviate werten Filter im HNSW-Graph aus. Chroma und LanceDB filtern erst nach der Top-K-Suche, was bei selektiven Filtern (z.B. „nur Mandant 42") zu schlechtem Recall führt. Wer Multi-Tenant-Trennung braucht, sollte das vor der Wahl prüfen.

Wie sich die zehn Optionen unterscheiden

Die zehn Datenbanken lassen sich in vier Gruppen ordnen. Erste Gruppe: dedizierte Open-Source-Vektor-DBs in Rust oder C++ – Qdrant, Weaviate, Milvus. Diese sind für ANN-Suche gebaut, haben das beste Latenz-Profil bei mittlerer Datenmenge und unterstützen Multi-Tenant-Filter sauber. Qdrant führt bei Self-Hosted-Setups in der Schweiz, Weaviate punktet mit GraphQL und nativer Hybrid-Suche, Milvus mit GPU-Acceleration für sehr grosse Korpora ab 100 Mio. Vektoren.

Zweite Gruppe: Erweiterungen bestehender Datenbanken – pgvector (Postgres), RediSearch (Redis), Elasticsearch kNN. Diese gewinnen, wenn die Basis bereits läuft. pgvector v0.8+ (Mai 2026) bringt HNSW und IVFFlat, ACID-Transaktionen aus Postgres, Volltext via tsvector im gleichen Query – für KMU mit Postgres-Stack oft die richtige Wahl. RediSearch passt, wenn Redis schon als Cache existiert; Elasticsearch ist die natürliche Wahl in Setups, die ohnehin auf hybride Keyword+Vektor-Suche angewiesen sind.

Dritte Gruppe: Managed Cloud – Pinecone als reines SaaS. Pinecone Serverless seit 2024 eliminiert Cluster-Verwaltung; Storage und Compute werden separat bepreist. Für ressourcenarme Teams ohne DevOps-Kapazität ist Pinecone schnell produktiv – gegen einen Drittland-Transfer.

Vierte Gruppe: spezielle Profile – Chroma (Prototyping, DuckDB-basiert, einfachste API), Vespa (Yahoo-Origin, sehr performant für kombinierte structured+vector Queries, hohe Lernkurve), LanceDB (columnar Lance-Format, embedded in Python/JS, gut für lokale Apps und Notebooks).

Der technische Kern ist bei allen zehn ähnlich: HNSW als Standard-Index, Cosine/Dot/Euclidean als Distanz-Metriken, Top-K-Suche mit Filtern. Was sich unterscheidet ist das Drumherum – Cluster-Mode, Backup, Authentifizierung, Observability, Treiber-Reife in verschiedenen Sprachen.

Auswahl in 5 Schritten

1. 01Datenvolumen schätzen: weniger als 100.000 Vektoren -> pgvector oder Chroma reichen; 100.000 bis 50 Mio. -> dedizierte DB; über 100 Mio. -> Milvus oder Vespa prüfen.
2. 02Hosting-Constraint klären: müssen die Daten in EU/CH bleiben? Wenn ja, Pinecone als Cloud-only ausschliessen oder dessen EU-Region plus TIA bewerten.
3. 03Filter-Anforderung prüfen: payload-indexierte Filter (Mandant, Datum, Vertraulichkeit) sind in Qdrant und Weaviate stark, in Chroma und LanceDB schwächer.
4. 04Stack-Integration beachten: Postgres bereits da -> pgvector ohne zweite DB; Redis als Cache da -> RediSearch; Elasticsearch da -> kNN dort.
5. 05Team-Wissen einrechnen: kein Docker/DevOps -> Pinecone Cloud oder Qdrant Cloud; SQL-Komfort -> pgvector; Kubernetes-Erfahrung -> Milvus oder Vespa möglich.

Wann welche Datenbank passt

Wer bereits Postgres betreibt und unter 5 Mio. Vektoren pro Mandant erwartet, sollte pgvector zuerst probieren. Eine Migration auf Qdrant ist immer noch möglich, falls die Skalierung kommt, aber der Einstieg ist mit pgvector erheblich günstiger – keine zweite Datenbank, keine separaten Backups, gleiche ACID-Garantien.

Wer ohne Postgres startet oder mehrere Mandanten getrennt halten muss, ist mit Qdrant gut bedient. Eine Collection pro Mandant, payload-indexierte Filter für Datum und Vertraulichkeit, Snapshots in Hetzner-Storage-Box. Das Setup kostet einen Tag, danach läuft es über Jahre stabil.

Weaviate passt, wenn GraphQL als API-Stil gewünscht ist und multi-modal (Text + Bild + Audio in einer Collection) gebraucht wird. Milvus lohnt erst ab 100 Mio. Vektoren oder bei GPU-Bedarf – für eine 5-Personen-Treuhand mit 500.000 Dokumenten ist Milvus Overkill.

Chroma ist gut für Prototypen und Jupyter-Notebooks – schnelles Setup, kein Cluster, in 10 Minuten produktiv. Pinecone passt, wenn das Team keine DevOps-Kapazität hat und Drittland-Transfer akzeptiert ist; produktiv typisch im US-Kontext oder für offene Recherche-Use-Cases ohne PII.

Elasticsearch kNN ist die Wahl, wenn hybrid Keyword+Vektor in einer Anfrage gebraucht wird und Elasticsearch bereits läuft. Redis mit RediSearch passt für Setups, in denen niedrige Latenz unter 10 ms entscheidend ist und Daten ohnehin in Redis liegen – z.B. für Echtzeit-Empfehlung. Vespa ist die richtige Wahl für komplexe Ranking-Pipelines mit vielen Signalen (Embedding + Score + Time-Decay); die Lernkurve ist steil, aber das Ergebnis flexibler als bei den anderen.

LanceDB ist die Embedded-Option: keine Cluster-Verwaltung, läuft im gleichen Prozess wie die Anwendung, gut für lokale Desktop-Tools oder kleine on-prem-Installationen ohne Netzwerk-Sichtbarkeit.

Wann eine dedizierte Vektor-DB nicht nötig ist

Bei sehr kleinen Datenbeständen – unter 10.000 Einträgen – ist jede dedizierte Vektor-DB Overkill. Eine SQLite-Tabelle mit dem sqlite-vec-Plugin oder eine numpy-Array-Datei mit Brute-Force-Cosine-Suche reichen aus und sind erheblich einfacher zu betreiben. Die Antwortzeit bleibt unter 50 ms, der Code unter 30 Zeilen.

Auch dann überflüssig, wenn die Daten in einen LLM-Kontext passen. Moderne Modelle akzeptieren 200k bis 2M Tokens Kontext (Stand Mai 2026: das aktuelle Claude-Spitzenmodell mit 1M, Gemini 2.5 Pro mit 2M); eine 30-Seiten-Wegleitung passt vollständig in den Prompt. Wer mit weniger als 100.000 Tokens auskommt, braucht weder Embedding noch Retrieval – das spart einen Tag Pipeline-Bau und reduziert die Fehlerquelle.

Für reine Volltext-Suche ohne semantische Komponente sind Meilisearch, Typesense oder Elasticsearch ohne kNN passender. Wer „Müller" sucht und nur „Müller" finden will (nicht „Schmidt", weil semantisch verwandt), bekommt mit klassischem BM25 bessere Ergebnisse als mit Embedding-Suche.

Ungeeignet ist eine Vektor-DB auch für Use-Cases, in denen Updates dominieren. Vektor-Indizes sind für „append plus search" optimiert; häufige Updates an einzelnen Vektoren (z.B. bei einem User-Profil, das sich ständig ändert) zwingen zum Re-Index und kosten Performance. In solchen Fällen ist eine klassische Datenbank mit getriggerten Re-Embeddings überlegen.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. Qdrant documentation and benchmarks (HNSW, payload indexes, snapshots) · 2026-05
2. Weaviate Cloud pricing – Flex, Standard, Premium tiers (October 2025 restructure) · 2026-05
3. pgvector v0.8+ release notes – HNSW and IVFFlat indexes · 2026-04
4. MarkTechPost – Best Vector Databases in 2026: Pricing, Scale Limits, Architecture Tradeoffs · 2026-05
5. Pinecone Serverless pricing and EU region (eu-west-1) · 2026-05
6. ANN-Benchmarks – open methodology for nearest-neighbour search · 2026-03