Milvus-Review: die vollständigste Vektordatenbank im Betrieb

Milvus ist eine Open-Source-Vektordatenbank für Ähnlichkeitssuche über Einbettungen, geschrieben in Go und C++, unter LF AI & Data entwickelt; Zilliz ist der wichtigste Beitragende. Die Position dieses Reviews: Bei Skala ist es die vollständigste Engine, die Open Source bietet, und zugleich die teuerste im Betrieb. Die eigentliche Frage ist also, wer den Cluster betreibt, nicht welcher Indextyp gewinnt.

Es besetzt die Retrieval-Schicht eines RAG- oder Suchstacks: den Speicher für Vektoren, Metadaten und seit 3.0 auch lange Texte, der Top-k-Abfragen unter Filtern beantwortet. Es konkurriert mit Qdrant und Weaviate als selbst hostbare Pendants, mit Pinecone als rein verwaltetem Dienst und mit pgvector für Teams, die keine weitere Datenbank betreiben wollen. Zilliz Cloud, verkauft vom Unternehmen, das den Großteil des Codes beiträgt, ist der verwaltete Zwilling des Apache-lizenzierten Projekts.

Was es ist

Es gibt drei Deployment-Formen, und sie sind nicht gleichwertig. Milvus Lite ist eine lokale Datei, die der Python-Client für Experimente öffnet; Standalone ist ein Knoten mit seinen Abhängigkeiten; der verteilte Modus ist das eigentliche Produkt, ein Kubernetes-Deployment mit getrennter Speicher- und Rechenschicht.

• Apache-2.0-Lizenz, ein LF-AI-&-Data-Projekt mit Zilliz als Hauptbeitragendem; geschrieben in Go und C++, die Suchkerne basieren auf FAISS, HNSW, DiskANN und SCANN.
• Aktuelle Version 3.0.2, veröffentlicht am 20. September 2026, parallel wird der 2.6-Zweig mit 2.6.25 weitergepflegt.
• Indexauswahl: HNSW, IVF, FLAT, SCANN, DiskANN, GPU-Indizes wie NVIDIA CAGRA, dazu Quantisierung und mmap für speichergebundene Daten.
• Dichte Vektoren, gelernte sparse Vektoren und serverseitiges BM25 in einer Collection, mit Hybridsuche und Reranking in einem einzigen Request.
• Multi-Tenancy auf Datenbank-, Collection-, Partitions- oder Partition-Key-Ebene, hinter Authentifizierung, TLS und RBAC.
• 3.0 bringt External Collections über Parquet, Lance, Iceberg und Vortex, Snapshots sowie Schemaänderungen mit Backfill im laufenden Betrieb.
• Die Integrationen, die ein Retrieval-Stack erwartet: LangChain, LlamaIndex, Attu für die Administration, Prometheus und Grafana für Monitoring, dazu Spark- und Kafka-Konnektoren.

Wie es funktioniert

Milvus trennt Datenebene und Steuerungsebene in vier Schichten. Zustandslose Proxies nehmen Requests an und reduzieren die Ergebnisse; genau ein Koordinator ist aktiv und plant DDL-, Routing-, Query- und Kompaktionsaufgaben; Worker-Nodes führen aus, ohne eigene Daten zu halten; der Speicher ist geteilt. Die Dokumentation beschreibt Woodpecker als einen Write-Ahead-Log ohne lokale Festplatte, der direkt in den Object Storage schreibt, wodurch die Verwaltung lokaler Platten aus dem Schreibpfad fällt.

Ein Schreibvorgang wird zuerst ins WAL geschrieben, ist im Streaming Node als wachsende Daten abfragbar und bleibt dort, bis die Kompaktion sie versiegelt; der Data Node baut dann die Indizes, der Query Node lädt sie. Eine Suche läuft lokal gegen wachsende Daten und parallel über versiegelte Segmente, wobei die Ergebnisse auf drei Ebenen reduziert werden, bevor der Proxy sie zurückgibt. Jeder Hop ist eine Stelle, an der Konsistenzlevel und Replica-Platzierung die Latenz verändern.

Erste Schritte

Der kürzeste Weg ist Milvus Lite über den Python-Client: ein pip install und ein Dateiname, kein Server, kein etcd, kein Object Storage. Derselbe Client zeigt dann auf einen Server oder einen Zilliz-Cloud-Endpunkt, indem sich uri und token ändern, weshalb Prototypen meist ohne Umbau weiterleben.

# pip install -U pymilvus  — Milvus Lite stores everything in one local file
from pymilvus import MilvusClient

client = MilvusClient(uri="./milvus_demo.db")

client.create_collection(
    collection_name="papers",
    dimension=768,        # must match the embedding model
    auto_id=True,
    metric_type="COSINE",
)

client.insert(collection_name="papers", data=[
    {"vector": v, "title": t, "year": y} for v, t, y in rows
])

hits = client.search(
    collection_name="papers",
    data=[query_vector],
    limit=5,
    filter="year >= 2023",
    output_fields=["title", "year"],
)
print([(h["entity"]["title"], round(h["distance"], 3)) for h in hits[0]])

Der vereinfachte Client versteckt Schema, Indexparameter und dynamische Felder, und das ist das richtige Niveau für einen Prototyp. Im Produktivbetrieb müssen diese Entscheidungen explizit fallen: Metric-Typ, Indextyp, Quantisierung, mmap, Partition Keys für Tenancy und ein Konsistenzlevel pro Request.

Hybridsuche und Skala

Milvus hält dichte Vektoren, gelernte sparse Vektoren und BM25-Ausgabe in derselben Collection, sodass ein Request mehrere Vektorsuchen ausführen und verschmelzen kann. Reranking zog mit 3.0 in den Server: Die Function Chain API kombiniert Score-Transformation, modellbasiertes Reranking und Kandidatenkürzung in einem Suchaufruf, gewichtetes Reciprocal-Rank-Fusion kam in 3.0.1 dazu.

• BM25 wird serverseitig aus dem Rohtext berechnet, die Anwendung schickt also keine Tokens zum Datenbankhin und zurück.
• Die sparse Suche in 3.0 ist um SINDI neu gebaut, mit Block-Max WAND und Block-Max MaxScore je nach Lastprofil wählbar.
• Faceted Search auf dem ANN-Pfad liefert die obersten Facettenwerte mit COUNT und AVG im selben Request statt eines Over-Fetch im Client.
• TEXT-Felder halten Werte unter 64 KB inline, größere in Partitions-LOB-Dateien, sodass Quelltext und Vektoren aus einem Speicher gelesen werden.

Die Release Notes zu 3.0.0 nennen zwei interne Zahlen: der komprimierte BM25-Index ist bei vergleichbarem Recall etwa dreimal kleiner als der sparse Index der 2.6, und SINDI erreicht bei gelernten sparse Embeddings bis zu etwa zehnmal das QPS von MaxScore. Beides sind eigene Messungen des Anbieters. Die informativere Zahl steht in 3.0.2: Ein atomarer Refcount-Hotspot, der rund 48% der Leaf-CPU-Zeit in der Suche ausgemacht hatte, wurde entfernt. Gefilterte Suche hatte diese Steuer vorher gezahlt, und die meisten produktiven Vektordaten sind gefiltert.

Betrieb und Kosten

Milvus selbst zu hosten bedeutet, Failover des Koordinators, Replica-Platzierung, Kompaktionsverhalten und Indexbau-Kapazität selbst zu verantworten. Zilliz Cloud verkauft dieselbe Engine ohne diese Entscheidungen, und die Preisseiten sagen klar, was abgerechnet wird.

• Free Tier: 5 GB Speicher, 2.5 Millionen vCUs pro Monat und bis zu 5 Collections, nur Community-Support.
• Dedicated-Rechenleistung wird mit $0.273 pro CU-Stunde für Performance- und Capacity-optimierte Cluster gelistet, mit $0.41 für Tiered-Storage-Cluster.
• Speicher wird mit $0.025 pro GB-Monat für Dedicated-Cluster gelistet und stündlich abgerechnet; Backups ebenfalls $0.025 pro GB-Monat.
• Enterprise beginnt bei $197 pro Monat mit 99.95% Uptime-SLA, Audit-Logs, SSO und VPC-Peering.
• On-Demand-Compute für lake-große Query- und Indexjobs wird mit $0.41 pro CU-Stunde gelistet und pro CU-Minute abgerechnet.

Wo es hakelt

Die Schwächen zuerst. Milvus ist ein verteiltes System mit Koordinator, WAL, Object Store und Indexworkern, und diese Oberfläche wird als Betriebsaufwand sichtbar, lange bevor sie als Fähigkeit erscheint. Schemaänderungen, Indexneuaufbauten und Kompaktions-Tuning sind alltägliche Aufgaben mit alltäglichen Fehlermodi; allein 3.0.2 bringt Fixes für eine Replica, deren Channels alle auf einem Query Node landeten und sie unbedienbar machten, und für WAL-Fencing, das Schreibvorgänge 45 bis 60 Sekunden stilllegte.

• Setup-Kosten: Der verteilte Modus ist ein Kubernetes-Deployment mit Operatoren, kein docker run.
• Kleine Workloads zahlen die Architektur: unter zehn Millionen Vektoren ist ein Single-Binary-Store einfacher und meist schneller abzufragen.
• Versionsverfall ist teuer: 2.6 und 3.0 werden parallel gepflegt, Storage V3 ist standardmäßig aus, und wer es einschaltet, verliert den Rückweg auf 2.6.
• Das öffentliche Vergleichsmaterial stammt größtenteils vom Anbieter; unabhängige Zahlen bei festem Recall-Ziel sind selten.

Diese Tabelle ist als Vergleich der Aufmerksamkeitskosten zu lesen, nicht der Funktionen. Milvus gewinnt, wenn der Lastfall groß, gefiltert und multi-tenant ist, und verliert überall dort, weil Koordinator, WAL und Indexworker jemanden im Bereitschaftsdienst brauchen.

Fazit

Milvus ist die richtige Engine für ein Team, das verteilte Systeme schon betreibt und einen Lastfall hat, der sie rechtfertigt. Es ist die falsche Erstwahl für ein Produkt, das seine Retrieval-Qualität noch findet, wo Iterationstempo wichtiger ist als Tail-Latenz.

1. Nehmen Sie es, wenn Sie Hunderte Millionen Vektoren, strikte Tenant-Isolation oder dichte und sparse Suche in einem Speicher brauchen.
2. Selbst hosten nur, wenn jemand im Team bereits stateful Kubernetes-Dienste betreibt; sonst mit Zilliz Cloud starten und den Migrationsweg offen halten.
3. Für ein RAG-Prototyp unter wenigen Millionen Chunks überspringen: Lite für das Experiment, dann ein Single-Binary-Store für den Produktivbetrieb.
4. Überspringen Sie es, wenn Postgres die Daten schon hat und Vektorsuche nur ein Nebenfeature ist; pgvector behält eine Backup-Geschichte und einen Satz Zugangsdaten.
5. Welchen Weg Sie auch wählen: Version pinnen und die Release Notes lesen, denn 3.0 hat Speicherformat-Defaults geändert und die neuen Indizes sind opt-in.

Eine Vektordatenbank, die Sie nicht betreiben können, ist keine günstigere Datenbank. Sie ist ein unbezahlter Betriebsvertrag mit angehängtem Index.

Quellen

1. Milvus: Architektur-Übersicht
2. Milvus: Release Notes
3. Milvus-Releases auf GitHub
4. Milvus-README: Funktionen und Lizenz
5. Zilliz-Cloud-Preise
6. Zilliz Cloud: Listpreis