Qdrant vs Weaviate vs Milvus

The three databases differ most in what must be running before queries and writes succeed. Qdrant's distributed mode uses Raft consensus for cluster topology and collection structure, splits each collection into shards across nodes, and keeps extra copies through a replication factor, which doubles storage at a factor of 2. Qdrant's distributed deployment docs recommend at least three nodes for production so quorum survives a node failure, with a shard count that is a multiple of the node count. Storage is the other constraint: Qdrant needs block-level storage with a POSIX-compatible file system and cannot use NFS or S3 as primary storage, with SSD or NVMe recommended. Before sizing, confirm that your storage class meets this requirement, because it decides whether Qdrant can run on your existing infrastructure at all.

Weaviate's replication is leaderless, disabled by default, and enabled per collection with a replication factor. Consistency is tunable at query time through ONE, QUORUM and ALL, so the choice is a per-workload decision rather than a single cluster setting. The practical risk is the default: a team that deploys Weaviate and creates collections without configuring replication runs without replicas. Weaviate's operational footprint is a single server type, but its replication and consistency behavior lives in collection definitions and application queries. Your backup and monitoring plans should cover each collection's replication settings, and you should confirm with Weaviate how those settings are checked after upgrades.

Milvus separates storage from compute more explicitly than either alternative. Its distributed architecture includes stateless proxies, a coordinator and worker nodes, with etcd holding metadata, MinIO, S3 or Azure Blob holding objects, and Woodpecker, Kafka or Pulsar acting as the write-ahead log. Each of these is a separate dependency with its own failure modes, sizing, backup path and monitoring. The Milvus architecture overview documents how these pieces interact. Milvus Lite and Standalone reduce this count for smaller workloads, but the team should choose a write-ahead log and object store early and list the owner of each component before committing to the distributed mode.

Implementation effort starts with the deployment path you pick, and the three platforms offer very different routes. Qdrant runs as a single binary in Docker, and the documented production paths are the managed Qdrant Cloud, a community-supported Kubernetes Helm chart and an enterprise Kubernetes operator that comes with Qdrant Private Cloud. The Helm chart does not include enterprise features such as zero-downtime upgrades and automatic shard rebalancing, so a self-hosted team on the open-source path should confirm which of those operations it will perform by hand. Weaviate's README lists Docker, Kubernetes and Weaviate Cloud as installation options, which makes the first deployment straightforward, but the production choices sit in the configuration. Milvus has three modes: Milvus Lite as a Python library for prototyping, Standalone on one machine, and Distributed as a Kubernetes-native cluster. Standalone is not a substitute for Distributed when you need separate scaling of components, so decide the mode before the first build, not after.

Securing the defaults is the first task on every platform, and the gap is widest on Qdrant. The Qdrant security documentation states that self-deployed instances listen on all network interfaces and have no authentication configured by default, so the team must set API keys, enable TLS and restrict network exposure before any data is loaded. Weaviate's self-hosted authentication offers API key, OIDC and anonymous access, with anonymous access discouraged outside development, and its RBAC API assigns custom roles. Milvus documents authentication, TLS and role-based access control. In each case, confirm the controls in your own environment, run a scan against the deployed endpoints and record the result as evidence. Sizing storage is the next decision. Qdrant needs block-level storage with a POSIX-compatible file system and cannot use NFS or S3, with SSD or NVMe recommended. Milvus Distributed separates object storage (MinIO, S3 or Azure Blob), metadata in etcd and a write-ahead log, so each of those services becomes a component you must size, back up and monitor.

Shard and replica planning and later migration are where early choices become expensive. Qdrant's distributed mode uses Raft for cluster topology, splits collections into shards and stores extra copies through a replication factor, which doubles storage at a factor of 2. The documentation recommends at least three nodes for production so quorum survives a node failure, and a shard count that is a multiple of the node count. Weaviate replication is disabled by default and set per collection with a replication factor, and consistency levels are chosen at query time, so the team must decide these per collection before loading. Milvus shards and partitions are set through its collection and partition design. Migration is cheaper when the collection schema, payload fields and embedding model version are documented before the first load, because moving between vector stores usually means re-indexing from source data. Ask each vendor or your implementation partner for the export and import path for your data size and confirm it in a test environment first.

The choice between Qdrant, Weaviate and Milvus is easier to make well when you know what an outside partner would and would not do for you. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms inside your own cloud accounts, data centers or air-gapped networks, so the vector store you pick would run in your infrastructure under your keys, your identity provider and your backup policy. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. That makes it practical to ask a partner to stand up one of these engines, but it also means the decision should be settled before the statement of work is written.

Let your data and team drive the pick, not a DeployOpen preference. The questions that matter are concrete: how many vectors you expect to hold and how fast they grow, whether you need metadata filtering with access control on each query, whether you can run a three-node cluster with block storage, and whether your staff already operate etcd and an object store, as a Milvus deployment requires. If your team is small and a single service is enough, a narrower scope for one engine is usually easier to price and verify than a broad platform project. Ask any partner to show how the chosen engine's authentication, TLS and role settings will be configured, because Qdrant's security documentation states that self-deployed instances are not secure by default. DeployOpen does not issue audit reports, attestations or certifications. If your compliance program needs evidence about access control, logging or backup for a vector store, DeployOpen can prepare the configurations, controls and records that an independent auditor or certification body would review, but the assessment itself comes from that auditor. Confirm with your assessor which evidence they will accept, such as exported audit logs or documented role assignments, before you commit to a design. Ask any provider for their written deliverables, the acceptance criteria and who keeps the runbooks after handover.