Milvus
What is HardGraph? HardGraph publishes curated, provenance-backed agent skills grounded in reproducible vendor documentation.
Milvus is built around one primitive — approximate nearest-neighbor search over vectors, with scalar fields for filtering. Storage layout, index structures, and consistency model all serve that workload first; it is not a general database with a vector column bolted on.
Index type drives everything downstream
The index choice trades recall, latency, memory, and build time, and switching later means re-indexing the whole collection. HNSW is the usual default when the dataset fits in memory: high recall, fast, memory-hungry, slow to build. IVF and its quantized variants (IVF_SQ8, IVF_PQ) trade recall for a smaller footprint and faster build once vector count outgrows memory. DiskANN targets datasets too large for memory at all. No default is universally correct — it's a function of dataset size, memory, and latency budget.
Milvus vs Zilliz Cloud vs pgvector
Zilliz Cloud is Milvus's own managed offering — same engine, no cluster operations. Self-hosting is justified by data residency or scale that makes managed pricing worse, not by default. pgvector is the other direction: if the workload already lives in Postgres with a moderate vector count and doesn't need Milvus's index variety or horizontal scaling, an extension beats a second data store. Reach for Milvus when vector search is the primary workload, the corpus is large enough that index choice matters, or partition-level multi-tenancy is a real requirement.
Schema, collections, and partitions
A collection is one schema: a vector field with its own index and metric type, scalar filter fields, and a primary key. Partitions subdivide a collection along a tenant or time-bucket dimension so a filtered search can skip whole partitions — only worthwhile when the partition key is the dimension queries actually slice on; over-partitioning fragments the index instead of saving work. Metric type (L2, inner product, cosine) must match how embeddings were produced — a mismatch silently degrades results without an error.
Consistency is a search-correctness question, not a durability one
Writes are asynchronously indexed; a search right after insert can miss the new row depending
on the consistency level. Strong guarantees a search sees all prior writes at a latency cost;
Bounded (the common default) allows a small staleness window; Eventually gives no guarantee.
Get this wrong in a write-then-search flow — common in agent memory or dedup patterns — and the
failure is silent: the row exists, the search doesn't see it yet.
What to verify rather than recall
Index parameter names and defaults (M/efConstruction for HNSW, nlist/nprobe for IVF),
MilvusClient method signatures, and deployment resource requirements change across releases and
differ between SDKs. Confirm against the mirrored corpus under references/vendor/ or the live
docs rather than a remembered parameter — a stale one fails at index-build time.