MILVUS · TECH
Milvus: Cluster-Vektor-Datenbank für mehr als eine Milliarde Vektoren
Milvus ist eine Apache-2.0-Vektor-DB mit getrennter Compute- und Storage-Schicht. GPU-Acceleration, HNSW plus IVF plus DiskANN, für Volumen ab 100 Mio. Vektoren.
Recherche & Faktencheck: DuneDive LLC · Stand: 2026-05
Was ist Milvus?
Milvus ist eine Open-Source-Vektor-Datenbank unter Apache-2.0-Lizenz, entwickelt seit 2019 von Zilliz und seit 2020 als Top-Level-Projekt der LF AI & Data Foundation. Stand Mai 2026 ist Version 2.5+ aktuell. Milvus unterscheidet sich von Qdrant und Weaviate durch eine disaggregierte Cluster-Architektur: Compute-, Storage- und Coordinator-Schicht laufen als separate Services, die unabhängig skalierbar sind. Diese Trennung erlaubt Setups, in denen die reine Vektor-Suche auf vielen Read-Replicas läuft, während Updates und Index-Builds an einer kleinen Compute-Schicht hängen.
Milvus unterstützt mehrere Index-Typen parallel: HNSW (Standard, Cosine/Dot/Euclidean), IVF_FLAT (klassischer Inverted File), IVF_PQ (Produkt-Quantisierung für kleinere RAM-Footprints), DiskANN (SSD-optimiert für Datasets, die nicht in den RAM passen), und GPU_IVF_FLAT plus GPU_IVF_PQ (FAISS-basierte GPU-Indizes via cuVS und Raft). Die Wahl des Index ist pro Collection und kann an die jeweilige Last angepasst werden. Für typische CH-KMU-Lasten reicht HNSW; für Volumen ab 500 Mio. Vektoren mit knappem RAM lohnt DiskANN.
Die Cluster-Architektur stützt sich auf etcd (Coordinator-State), MinIO/S3 (Storage), Pulsar/Kafka (Message-Queue) und mehrere Milvus-eigene Worker-Pods (Query, Data, Index, Root-Coord). Für kleinere Setups gibt es seit 2024 Milvus Lite – eine embedded Variante als Python-Pip-Paket, mit DuckDB-ähnlichem Profil. Und Milvus Standalone – ein Single-Node-Docker-Container ohne Coordinator-Stack.
Die Managed-Cloud-Variante heisst Zilliz Cloud und ist in mehreren AWS- und GCP-Regionen verfügbar, darunter eu-central-1 (Frankfurt). Self-Hosted läuft auf Kubernetes mit dem Helm-Chart oder als Docker-Compose-Stack.
Warum es wichtig ist
Milvus wird relevant, sobald die Vektor-Last die Grenzen einer Single-Node-DB sprengt. Drei Szenarien treffen das: ein Mandantenstamm mit Millionen von Dokumenten, eine Plattform mit Hunderten von Mandanten und je eigener Daten-Insel, oder ein Forschungs-Use-Case mit Embeddings über sehr grosse Corpora (z.B. Schweizer Rechtsprechung der letzten 30 Jahre).
Für eine 5-Personen-Treuhand ist Milvus typisch überdimensioniert. Sobald die Plattform aber an Multi-Mandanten-Setups skaliert, in denen pro Mandant 1-10 Mio. Vektoren gespeichert werden, fällt die Architektur-Entscheidung anders. Milvus hat zwei Eigenschaften, die in diesem Profil zählen.
Erstens: Compute-Storage-Trennung. Read-Last skaliert über zusätzliche Query-Nodes, ohne dass die Storage-Schicht angefasst wird. Backup läuft auf der Storage-Seite (S3-kompatibler Objektspeicher), unabhängig von der Compute-Seite. Für einen Audit unter Art. 957a OR ist die saubere Trennung von Daten und Verarbeitung vorteilhaft – die Datenebene lässt sich versionieren und unabhängig sichern.
Zweitens: Index-Flexibilität. Eine Collection kann mit HNSW starten und später auf DiskANN umindexieren, falls der RAM-Footprint zu gross wird. IVF_PQ erlaubt eine Reduktion des RAM-Footprints um Faktor 10-30 bei moderatem Recall-Verlust. Für Setups, in denen Hardware-Kosten gegen Recall-Qualität abgewogen werden müssen, gibt Milvus mehr Hebel als Qdrant oder Weaviate.
Der Betriebsaufwand ist deutlich höher als bei Qdrant. Wer Milvus produktiv betreibt, braucht Kubernetes-Erfahrung, Verständnis für etcd-Backups, Monitoring auf mehreren Service-Ebenen. Für eine CH-Treuhand ohne Plattform-Ambition ist das selten gerechtfertigt – für eine Branchen-Plattform mit Skalierungs-Plan dagegen oft die richtige Wahl.
Wie es funktioniert
Milvus folgt einem service-orientierten Cluster-Modell. Eine Collection wird über den Python-, Java-, Go-, Node- oder Rest-Client angelegt mit Schema-Definition: Felder (vector, int64, varchar, json, …) und Index-Konfiguration.
Beispiel via PyMilvus: from pymilvus import MilvusClient client = MilvusClient(uri="http://milvus:19530") client.create_collection(collection_name="docs", dimension=1536, metric_type="COSINE", index_params={"index_type": "HNSW", "M": 16, "efConstruction": 200})
Import per insert([{vector: [...], doc_id: "x", client_id: 42, content: "..."}]). Milvus akzeptiert Batches bis 10 MB pro Request; bei grösseren Lasten lohnt der Bulk-Import via S3-Datei (Parquet, JSON).
Suche per search(collection_name="docs", data=[query_vector], limit=10, filter="client_id == 42", output_fields=["content"]). Filter sind als Boolean-Expression formuliert (Milvus-eigene Syntax mit ==, in, like). Die Filter werden im Index ausgewertet, nicht erst nach der Top-K-Suche, sofern für die gefilterten Felder ein Scalar-Index angelegt ist.
Multi-Tenant-Trennung läuft über Partitionen oder über separate Collections. Partitionen sind logische Teilbereiche einer Collection mit eigenem Filter-Kontext – eine Anfrage kann auf eine bestimmte Partition begrenzt werden, was im Index-Lookup schneller ist als ein Filter über das gesamte Set.
GPU-Indizes laufen über das milvus-gpu-Image und benötigen Nvidia-CUDA-12+. Eine Collection mit GPU_IVF_FLAT läuft 5-10x schneller in der Suche als der CPU-Äquivalent, kostet aber eine GPU im Cluster (typisch A10 oder L4 für Inference-Use-Cases).
Backup läuft über das milvus-backup-Tool: eine Collection wird als Snapshot in S3 geschrieben (Schema plus Daten plus Index-Metadaten). Recovery zieht den Snapshot zurück. Multi-Region-Replikation ist via Milvus 2.4+ Multi-Master-Konfiguration möglich, für die meisten Setups aber Overkill.
Milvus in 5 Schritten produktiv
- 01Architektur-Entscheidung: Milvus Lite (embedded, < 1 Mio.) vs Standalone (Single-Docker, < 50 Mio.) vs Cluster (Kubernetes, > 50 Mio.). Datenvolumen ehrlich schätzen.
- 02Helm-Chart oder Docker-Compose deployen; etcd, MinIO und Pulsar als Coordinator- und Storage-Schicht aufsetzen. Persistent-Volumes für alle Services.
- 03Collection planen: Dimension, Distanz, Index (HNSW Standard, IVF_PQ bei knappem RAM, DiskANN bei sehr grossen Sets, GPU_* nur mit Nvidia-Hardware).
- 04Partitionen oder separate Collections für Multi-Tenant einrichten; Scalar-Indizes auf Filter-Felder anlegen, sonst skaliert die Filter-Suche schlecht.
- 05Backup über milvus-backup-Tool in S3-kompatiblen Speicher konfigurieren; Monitoring per Prometheus auf Query-, Index- und Coordinator-Metriken.
Wann Milvus einsetzen
Milvus passt, wenn (a) die Datenmenge dauerhaft über 50-100 Mio. Vektoren liegt, (b) Read-Last unabhängig von Write-Last skaliert werden soll, (c) GPU-Acceleration für sehr hohe Such-QPS gebraucht wird oder (d) eine Multi-Region-Replikation Teil der Anforderung ist.
Konkrete Fälle: eine Branchen-Plattform für Treuhandbüros mit 200 Mandanten und je 500.000 Vektoren – 100 Mio. Vektoren ergeben in einer Collection-pro-Mandant-Struktur 200 Collections, was Qdrant noch handhabt, in Milvus aber sauberer in Partitionen einer Collection abgebildet werden kann. Ein juristisches Retrieval-System über Schweizer Bundesgerichts-Urteile der letzten 30 Jahre, das mit GPU-Indizes Antwortzeiten unter 5 ms bei 50 Mio. Vektoren liefern muss. Ein Empfehlungs-System mit nicht-linear ansteigender Last, in dem die Compute-Schicht autoscaled werden soll.
Zilliz Cloud (Managed) eignet sich für Setups, in denen Kubernetes-Betrieb nicht gewünscht ist und ein US-/EU-Cloud-Provider akzeptabel ist. Die EU-Region in Frankfurt deckt die meisten DACH-Fälle ab; für CH-strikte Fälle bleibt Self-Hosted in Hetzner oder Infomaniak die saubere Wahl.
Wann NICHT
Bei unter 10 Mio. Vektoren ist Milvus deutlich Overkill. Qdrant oder pgvector erledigen die Aufgabe mit einem Bruchteil des Betriebsaufwands. Eine Milvus-Cluster-Installation mit etcd, MinIO und Pulsar braucht 4-8 GB RAM Baseline allein für die Coordinator-Services; bei 100.000 Vektoren ist das absurd.
Wenn das Team kein Kubernetes-Know-how hat, ist Milvus die falsche Wahl. Milvus Standalone (Single-Node-Docker) reduziert die Komplexität, verzichtet aber auf die Cluster-Vorteile – wer Standalone fährt, ist mit Qdrant typisch besser bedient.
Für reine Multi-Modal-Use-Cases ohne Skalierung-Pressure passt Weaviate besser. Milvus hat keine eingebauten Embedding-Module – der Vektor muss extern berechnet und übergeben werden. Für Hybrid-Suche bietet Milvus seit Version 2.4 native BM25-plus-Dense, aber die GraphQL-Idiomatik von Weaviate ist ausgereifter.
Milvus Lite ist eine interessante Variante für Notebook-Use-Cases – als embedded Python-Paket ist es Chroma vergleichbar. Aber die Lite-Variante ist nicht API-kompatibel mit Cluster-Milvus in allen Details; ein direkter Lite-zu-Cluster-Pfad existiert nicht ohne Re-Konfiguration.
Vor- und Nachteile
STÄRKEN
- Disaggregierte Architektur – Read- und Write-Skalierung unabhängig
- Mehrere Index-Typen (HNSW, IVF, DiskANN, GPU) pro Collection wählbar
- GPU-Indizes für sehr hohe Such-QPS, FAISS-basiert via cuVS
- Apache 2.0, LF AI & Data Foundation, aktive Community
SCHWÄCHEN
- Hoher Betriebsaufwand mit etcd, MinIO, Pulsar als Cluster-Abhängigkeiten
- Kein eingebautes Embedding-Modul wie bei Weaviate
- Single-Node-Standalone verzichtet auf die zentralen Cluster-Vorteile
- Für KMU unter 10 Mio. Vektoren überdimensioniert
Häufige Fragen
Was ist der Unterschied zwischen Milvus und Zilliz Cloud?
Milvus ist die Open-Source-Software unter Apache 2.0. Zilliz Cloud ist das Managed-SaaS-Angebot von Zilliz (dem Hauptentwickler von Milvus). Zilliz Cloud nimmt den Betriebsaufwand ab – etcd, MinIO, Pulsar, Worker-Skalierung – gegen monatliche Kosten ab USD 65 pro Compute-Unit. EU-Region Frankfurt verfügbar; für CH-strikte Fälle bleibt Self-Hosted die Wahl.
Wann lohnt GPU-Indizierung?
Erst ab mehreren 100 Mio. Vektoren mit hoher Such-QPS (> 1000/Sekunde). Für typische Treuhand-Setups mit < 10 Mio. Vektoren und < 100 Anfragen pro Stunde reicht CPU-HNSW vollständig. GPU lohnt erst dann, wenn die Hardware-Kosten für mehrere CPU-Replicas die GPU-Kosten überschreiten.
Wie aufwendig ist der Cluster-Betrieb?
Spürbar. Ein produktiver Milvus-Cluster braucht laufendes Monitoring auf 6-8 Service-Pods (Root-Coord, Query-Node, Data-Node, Index-Node, Proxy plus etcd, MinIO, Pulsar). Updates müssen in der richtigen Reihenfolge laufen. Backup hat mehrere Komponenten. Plan: 4-8 Stunden Setup, 2-4 Stunden monatlicher Betriebsaufwand bei stabilem System. Wer das nicht stemmen will: Zilliz Cloud oder Qdrant.
Verwandte Themen
Quellen
PASSEND ZU IHREM STACK?