Qdrant: produktive Vektor-Datenbank für RAG und Semantische Suche

Was ist Qdrant?

Qdrant ist eine Open-Source-Vektor-Datenbank (Apache-2.0), die in Rust geschrieben ist. Sie wurde 2021 von Andrey Vasnetsov und Andrey Kachanov gestartet und ist seitdem zu einem der drei Standard-Tools für produktive Vektor-Suche geworden – neben Weaviate und Milvus. Stand Mai 2026 ist Version 1.12 aktuell, mit aktivem Community-Support, regelmässigen Releases und einer hybriden Cloud/Self-Hosted-Strategie.

Die Aufgabe einer Vektor-Datenbank: hochdimensionale Embedding-Vektoren (typisch 384 bis 3072 Dimensionen) speichern und in Millisekunden die nächsten Nachbarn zu einem Such-Vektor finden. Qdrant nutzt dafür HNSW (Hierarchical Navigable Small World), eine Graph-Indexstruktur, die selbst bei Millionen von Einträgen unter 50 ms Antwortzeit liefert – auf gewöhnlicher CPU, ohne GPU.

Neben dem reinen Vektor-Index speichert Qdrant pro Punkt einen JSON-Payload (z.B. Mandanten-ID, Datum, Vertraulichkeitsstufe, Dokument-ID). Auf jedem Payload-Feld kann ein Filter-Index gesetzt werden. Eine Anfrage kann damit kombiniert werden: „finde die 10 ähnlichsten Vektoren zu diesem Embedding – aber nur unter den Einträgen mit mandant_id=42 und datum > 2025-01-01". Dieses sogenannte Filtered Search arbeitet stabil und ist der Grund, warum Qdrant in Mandanten-getrennten Setups gut funktioniert.

Auf unserem Stack läuft Qdrant in einem Docker-Container mit 83 Collections, eine pro Use-Case oder Mandant. Persistenz über ein gemountetes Volume, Snapshots via REST-API in S3-kompatiblen Speicher, Replikation via Cluster-Mode optional.

Warum es wichtig ist

Vektor-Suche ist das Rückgrat jeder RAG-Pipeline. Wer hier auf eine schlechte Wahl baut, holt sich Skalierungsprobleme, Datenschutz-Probleme oder Vendor-Lock-in ins Haus.

Drei Eigenschaften machen Qdrant für den CH-Treuhand-Kontext geeignet. Erstens: Self-Hosted auf eigener EU-Hardware. Der Container läuft auf einem Hetzner-Server in Falkenstein oder Helsinki. Keine Daten verlassen die EU-Infrastruktur. Pinecone als Konkurrent ist nur als US-Cloud-Service verfügbar – für Mandantendaten unter revDSG ein Show-Stopper.

Zweitens: Distanz-Metriken und Filter. Qdrant unterstützt Cosine, Dot Product und Euclidean Distance – der wichtigste Punkt ist, dass diese Wahl pro Collection getroffen wird, nicht global. Embedding-Modelle mit normalisierten Vektoren (OpenAI, Cohere) laufen unter Dot Product etwas schneller als unter Cosine – bei grossen Datenmengen messbar. Filter-Performance ist der zweite Hebel: payload-indexierte Filter werden im HNSW-Graph ausgewertet, nicht erst nach der Top-K-Suche. Damit bleibt die Antwortzeit auch bei Filtern wie „nur Mandant X, nur 2025" stabil.

Drittens: Operativ ehrlich. Qdrant exportiert Prometheus-Metriken (Collection-Grösse, Such-Latenz, Index-Auslastung) und hat ein einfaches Backup-Konzept: Snapshots pro Collection, die als TAR in S3 oder lokal landen. Recovery ist ein API-Call. In einem Audit unter Art. 957a OR ist das nachvollziehbar – kein Black-Box-Provider, sondern eine Open-Source-Komponente mit dokumentiertem Verhalten.

Wie es funktioniert

Qdrant ist ein Single-Binary, das über gRPC und REST erreichbar ist. Die zentrale Einheit ist die Collection. Eine Collection legt fest: Vektor-Dimension, Distanz-Metrik, HNSW-Parameter und das Schema der Payload-Filter.

Beispiel-Anlage: eine Collection mandant_42_docs mit dimension=1536 (text-embedding-3-small), distance=Cosine, on_disk_payload=true. Die HNSW-Parameter m und ef_construct steuern die Index-Qualität – Defaults reichen bis ca. 1 Million Einträge; jenseits davon erhöht man m=16->32 und ef_construct=128->200 für bessere Recall-Qualität.

Upsert: pro Punkt geht ein Vektor plus Payload-JSON via PUT /collections/<name>/points. Der Payload kann beliebige Felder enthalten – für Filter empfehlen sich indexierte Schlüsselfelder: mandant_id, doc_id, source, confidentiality, created_at. Index anlegen via PUT /collections/<name>/index, ein- oder mehrfach (Keyword-, Integer-, Datetime-Index).

Suche: POST /collections/<name>/points/search mit dem Such-Vektor, einem Filter (must, should, must_not) und einem Limit. Antwort: eine Liste von Punkten mit Score (zwischen 0 und 1 bei Cosine), Payload und ID. Optional eine Score-Schwelle, um zu schwache Treffer zu filtern.

Für komplexe RAG-Pipelines bietet Qdrant Recommend, Discovery und Query (seit 1.10) – drei Schritte über die einfache Nächster-Nachbar-Suche hinaus. Recommend kombiniert positive und negative Beispiele. Discovery sucht in einem definierten Bereich des Vektor-Raums. Query verbindet mehrere dieser Schritte in einer einzigen Anfrage – nützlich für Rerank oder Multi-Stage-Retrieval.

Clustering und Sharding sind seit Version 1.10 stabil. Eine Collection kann über mehrere Nodes verteilt werden, mit Replikation für Hochverfügbarkeit. Für die meisten CH-Treuhand-Setups reicht eine Single-Node-Instanz – die Daten passen auf einen Server und die Last bleibt unter 100 Anfragen pro Sekunde.

Qdrant in 6 Schritten produktiv

1. 01Docker-Compose-Stack mit Qdrant-Image und gemountetem Volume aufsetzen, Port 6333 (REST) und 6334 (gRPC) intern halten.
2. 02Collections planen: pro Mandant oder pro Use-Case eine Collection, Dimension und Distanz-Metrik passend zum Embedding-Modell.
3. 03Payload-Indexes anlegen für alle Filter-Felder (mandant_id, doc_id, datum, vertraulichkeit) – sonst skaliert die Filter-Suche schlecht.
4. 04Ingestion-Pipeline bauen: Dokumente -> Chunks -> Embedding -> Upsert in Qdrant mit Payload. Batch-Grösse 100-500 Punkte pro Request.
5. 05Backup-Routine einrichten: täglicher Snapshot pro Collection in S3-kompatiblen Speicher, Retention 30 Tage.
6. 06Monitoring anbinden: Prometheus-Scraper auf /metrics, Grafana-Dashboard mit Such-Latenz, Index-Grösse und QPS.

Wann Qdrant einsetzen

Qdrant ist die richtige Wahl, wenn (a) Vektor-Suche auf eigener Infrastruktur laufen muss, (b) Filter über strukturierte Felder mit der Vektor-Suche kombiniert werden, oder (c) mehrere Mandanten oder Use-Cases sauber getrennt gespeichert werden sollen.

Konkrete Fälle: eine RAG-Pipeline für Mandanten-Dokumente, bei der jeder Mandant in einer eigenen Collection liegt – keine versehentliche Vermischung möglich. Eine Volltext-Suche über Korrespondenz mit Filter auf Mandant, Datum und Vertraulichkeit. Eine Ähnlichkeitssuche für juristische Präzedenzfälle, in der nur Urteile aus den letzten 10 Jahren berücksichtigt werden sollen.

Auch für Recommendation-Use-Cases ausserhalb von RAG ist Qdrant geeignet: ähnliche Produkte, ähnliche Mandanten-Profile, Anomalie-Erkennung auf Embedding-Basis. Die Cloud-Variante (Qdrant Cloud, gehostet in EU-Regionen) eignet sich für schnelle Pilotprojekte; produktiv wechselt man typisch auf Self-Hosted, sobald die Daten sensibel werden oder die Last vorhersehbar wird.

Wann NICHT

Bei sehr kleinen Datenmengen – unter 10.000 Einträge – ist Qdrant Overkill. Eine SQLite-Tabelle mit dem sqlite-vec-Plugin oder pgvector in einer ohnehin laufenden PostgreSQL-Instanz reichen. Erst ab 100.000 Einträgen oder bei strengen Antwortzeit-Anforderungen lohnt eine dedizierte Vektor-DB.

Auch ungeeignet: wenn das Team kein Docker- und kein YAML-Wissen hat und keinen Managed-Provider haben möchte. Qdrant ist betrieblich einfach, aber nicht null-Aufwand. Wer ohne IT-Ressourcen unterwegs ist, ist mit Pinecone Serverless oder Weaviate Cloud besser bedient – gegen Cloud-Kosten und Drittland-Transfer.

Für reine Volltext-Suche (BM25, TF-IDF) ohne semantische Komponente sind Elasticsearch, Meilisearch oder Typesense passender. Qdrant kann hybride Suche (Sparse + Dense Vektoren seit Version 1.10), aber wer ausschliesslich Stichwort-Suche braucht, hat dort die ausgereifteren Tools.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. Qdrant documentation – collections, payload indexes, HNSW parameters · 2026-05
2. qdrant/qdrant – GitHub releases and changelog · 2026-05
3. Qdrant blog – Hybrid search with sparse and dense vectors · 2026-02
4. Qdrant benchmarks – ANN-Benchmarks comparison · 2026-03