Milvus needs Kubernetes, etcd, and Kafka. ManyVector needs a bucket.
Milvus is purpose-built for billion-scale and brings the infrastructure bill to match: etcd for metadata, Pulsar or Kafka for messaging, MinIO for storage, and multiple node types — all running simultaneously. ManyVector gives you the same object-storage backend without the orchestration overhead.
Single binary
one process replaces 5+ services
No Kubernetes
runs anywhere Docker or a VM exists
Native BM25
hybrid search without sparse-vector workarounds
ManyVector vs Milvus, side by side.
Feature
ManyVector
Milvus
Deployment model
✓ Single binary — one process, one config file
✗ 5+ services: etcd, Pulsar/Kafka, MinIO, multiple node types
Kubernetes requirement
✓ Not required — runs on any VM or container runtime
✗ Designed for K8s — hard to avoid in production
Storage backend
✓ Native S3 / GCS / R2 / Azure / MinIO — your bucket
✓ MinIO / S3 via internal distributed architecture
Metadata store
✓ Built-in — no external coordination service
✗ Requires an external etcd cluster
Message queue
✓ Not required
✗ Requires Pulsar or Kafka
Namespace branching
✓ Copy-on-write instant branching built in
✗ Not supported
Full-text search (BM25)
✓ Native BM25 — no preprocessing required
✗ Sparse vectors only — no native BM25
Hybrid search (RRF)
✓ BM25 + vector with RRF fusion, built-in
✓ Supported via sparse + dense vector combination
Operational burden
✓ Low — one process to monitor and upgrade
✗ High — multi-service cluster management
Why teams switch from Milvus.
The services problem
Five failure domains before a line of app code.
Running Milvus in production meant running etcd, Kafka, MinIO, multiple Milvus node types, and monitoring all of them. That's five separate failure domains before we wrote a single line of application code.
Kubernetes dependency
We didn't want K8s just for vector search.
Milvus's Helm charts are good, but we didn't want to introduce Kubernetes just for vector search. ManyVector runs as a single container on our existing ECS cluster — no orchestrator upgrade required.
BM25 full-text search
No separate sparse-vector pipeline.
Milvus doesn't ship a native BM25 implementation. We were encoding sparse vectors with a separate pipeline just to get keyword search. ManyVector has it built in with no preprocessing required.
Common questions
Is ManyVector capable of handling the same scale as Milvus?
ManyVector targets teams operating from millions to hundreds of millions of vectors — the scale where Milvus's complexity is hard to justify. For workloads that genuinely require billions of vectors with sustained high-throughput writes, Milvus's distributed architecture is a legitimate choice. For most production use cases, ManyVector's object-storage model provides ample scale without the operational cost.
How does ManyVector store data without etcd or Kafka?
ManyVector uses your S3-compatible bucket as both the metadata store and the vector index store. All state is persisted directly to object storage using an internal log-structured format. There is no separate coordination service — the binary is the only process you run.
Can I use ManyVector without Docker or Kubernetes?
Yes. ManyVector ships as a static binary for Linux and macOS. Point it at an S3-compatible bucket (including local MinIO for development) and it runs. No container runtime, no orchestrator, no external dependencies.
How does hybrid search work in ManyVector compared to Milvus?
ManyVector runs BM25 and HNSW in parallel and merges results with Reciprocal Rank Fusion (RRF). In Milvus, hybrid search requires generating sparse vectors from a separate embedding step, then combining them with dense vectors. ManyVector's approach requires no preprocessing — just index your text and query.