Milvus and Open-Source Vector Search
Milvus is an open-source vector database for storing embeddings and running nearest-neighbour search with metadata filters. It organises data into collections with vector fields, scalar fields, keys, and indexes, so engineers can build semantic retrieval systems while controlling schema design, index choice, deployment model, and operational behaviour.
Vector search becomes necessary when exact keyword matching cannot capture semantic similarity. In RAG, recommendations, image search, and related systems, the application compares embedding vectors rather than strings. A normal relational index is not built for high-dimensional distance calculations across large corpora, especially when queries also need filters such as tenant, document type, timestamp, or permissions. Milvus exists to make those similarity queries practical while keeping enough database structure to integrate with production applications.
In Milvus, the main modelling unit is a collection, roughly the role a table plays elsewhere. A collection defines the vector field, its dimension, scalar metadata fields, and a primary key for updates and deletes. At ingest time, embeddings and metadata are written into the collection. At query time, Milvus compares a query embedding against indexed vectors, optionally narrows candidates with filters or partitions, and returns the closest matching IDs and fields.
The central engineering tradeoff is index choice. Exact flat search is simple and accurate but expensive as data grows. IVF-style indexes reduce work by searching selected regions of the vector space, which means tuning cluster and probe settings. HNSW often gives strong low-latency approximate search but can consume substantial memory. Disk-backed indexes relieve memory pressure at the cost of more I/O. The honest answer is always benchmark with your embeddings, filters, concurrency, and recall target.
Milvus is not just a library call; it is infrastructure. Engineers meet it when designing collection schemas, deciding whether raw documents live in Milvus or another store, selecting indexes, testing retrieval quality, and operating clusters. Compared with a managed vector database, it gives more control over deployment, data placement, and tuning. The cost is owning capacity planning, upgrades, observability, compaction, backups, and recovery rather than outsourcing those concerns.
Common questions
- Is Milvus the same thing as a vector index?
- No. A vector index is one component used to speed nearest-neighbour search. Milvus is a database around those indexes: it stores collections, vector fields, scalar metadata, primary keys, partitions, and query paths. The index determines how candidates are found, but Milvus also handles ingestion, filtering, retrieval, and operational concerns.
- Should I store the original text or documents in Milvus?
- It depends on access patterns and operational boundaries. Many systems store embeddings, IDs, and retrieval metadata in Milvus, then keep source text in object storage, a document database, or search infrastructure. Storing text in Milvus can simplify retrieval, but may couple document lifecycle, storage cost, and vector search scaling too tightly.
- How do I choose between Milvus and a managed vector database?
- Choose Milvus when control over deployment, data residency, tuning, or cost structure matters enough to justify running the system yourself. Choose a managed service when your team values simpler scaling, upgrades, backups, monitoring, and availability. The real question is not open source versus managed, but control versus operational responsibility.
- Is approximate vector search always worse than exact search?
- Not necessarily. Approximate search trades guaranteed exactness for lower latency or lower resource use, and it is often the practical choice at scale. What matters is measured recall for your application. If the retrieved context or recommendations remain good enough under realistic filters and load, approximate search may be the better engineering choice.