When should a self-hosted Qdrant leave its single node?
Stay on one Qdrant node while a restart or loss of the collection data is tolerable and the corpus fits on one machine. Move to a distributed cluster when downtime is no longer acceptable and your team can operate shards and replicas by hand. Three conditions push that decision: uptime requirements, growth, and the operations skills you have in-house. A single node has fewer moving parts, so there is less to configure, monitor and upgrade, and it is the right default for a proof of concept or an internal tool whose users can wait while a host restarts.
Uptime is the first test. Cluster mode is enabled with QDRANT__CLUSTER__ENABLED=true or the matching configuration entry, and Qdrant then uses the Raft consensus protocol to keep topology and collection structure consistent across nodes. The Qdrant distributed deployment docs recommend at least three nodes for production so quorum survives a node failure. Note that replication_factor defaults to 1, which keeps no extra copy, and for self-hosted Qdrant changing it after collection creation has no effect. If you need survival of a node loss, set the replication factor when you create the collection. Growth is the second test. Plan shard counts as a multiple of the node count, and consider the 12-shard layout the docs suggest for significant growth, which lets a collection expand to 2, 3, 6 and 12 nodes.
The third test is your operations capacity. In self-hosted clusters, automatic shard rebalancing and resharding are not available, so your team balances shards manually, and Qdrant Cloud handles that for you. Before committing, confirm who will run rebalancing, backups through Qdrant snapshots, upgrades and access control, and whether the Helm chart or enterprise operator fits your Kubernetes platform. Ask a vendor or an implementation partner to put those tasks in a written scope before you decide.
Which deployment fits which situation?
A single Qdrant node is the usual starting point for development, evaluation and pilots. One process holds every collection, which keeps setup short and lets a small team test embedding models, payload filters and chunking without operating a cluster. The trade-off is that one node has no peer to take over if it fails, and a rebuild may mean reloading data from your source systems or a snapshot. Because self-hosted Qdrant listens on all interfaces with no authentication by default, a pilot still needs API keys and network restrictions before it holds real documents.
- Failure scope: a host failure or bad disk takes the whole collection offline until the node returns.
- Replication default:
replication_factordefaults to 1, so no extra copy exists unless you set a higher value when you create the collection. - Cluster change: a cluster adds peers, but it does not remove the need for backups.
- Access control: set admin and read-only API keys before anyone outside the build team connects.
- Storage: use local block storage with an SSD or NVMe drive, since network file systems and object storage are not supported.
Before leaving this stage, confirm which source data can rebuild the collections and how long a reload would take on your hardware.
For a production workload where brief outages are acceptable, such as an internal search tool used during business hours, a single node often remains workable if backups are tested. The main risk is not data loss on a healthy day but downtime and restore time after a failure. A single node protects against cluster complexity, since there is no Raft topology, shard layout or peer network to manage. It does not protect against a node loss, and it does not spread query load across machines.
- Downtime exposure: a failed node stops search until you restart it or restore it elsewhere.
- Recovery path: snapshots and tested restores matter more than replicas at this tier.
- Growth limit: a single node scales vertically, so plan memory and disk for the corpus you expect within your review cycle.
- Cluster change: a multi-node cluster with a replication factor above 1 keeps a copy of each shard on another node, which doubles storage at a factor of 2.
- Operator effort: a cluster adds shard balancing and upgrade work that a self-hosted team must perform by hand.
Confirm the outage duration your users will accept in writing, and test whether a restore from your latest snapshot meets it.
A regulated production workload with uptime and recovery commitments usually needs a distributed cluster, since a single node cannot keep serving queries through a host failure. The Qdrant distributed deployment docs recommend at least three nodes so quorum survives one node failure, and they expect a shard count that is a multiple of the node count. Raft keeps topology and collection structure consistent across peers, but it does not decide your recovery targets. Those targets come from your own business continuity and regulatory obligations.
- Quorum: three nodes let the cluster keep quorum after losing one node, which a single node cannot offer.
- Replication: set
replication_factorat collection creation, because changing it later does nothing on self-hosted Qdrant. - Manual balancing: self-hosted clusters must rebalance and reshard shards by hand, while Qdrant Cloud automates this.
- Access and audit: JWT-based access control and JSON audit logging of authenticated operations are available, but they must be configured and retained.
- Evidence: DeployOpen can prepare configuration, runbooks and test evidence for an assessment, but auditors issue any attestation.
Ask your auditor or regulator which uptime and recovery standards apply, then confirm the recovery objectives and replication setup in writing before you choose a topology.
Single node and distributed cluster compared
This table compares a single self-hosted Qdrant node (option A) with a distributed cluster (option B) across topology, consensus, sharding, replication, failure behavior and operating effort. Read each row as the trade you accept: the cluster buys fault tolerance and headroom, and it adds configuration and manual balancing work that a single node does not carry.
| Factor | Option A: single node | Option B: distributed cluster |
|---|---|---|
| Deployment topology | One Qdrant instance, no peers to coordinate | Multiple nodes enabled with QDRANT__CLUSTER__ENABLED=true or the config file |
| Consensus | Not applicable | Raft keeps cluster topology and collection structure consistent |
| Shard layout | All shards on one node | Shards split across nodes; count should be a multiple of node count |
| Replication and storage cost | Replication factor 1 by default, one copy of data | Replication factor 2 doubles storage; factor is fixed at collection creation |
| Node failure behavior | Node loss means the service is down until restored | Replicas can serve data if quorum survives; plan at least three nodes |
| Rebalancing and resharding | Not applicable | Self-hosted clusters balance shards manually; Qdrant Cloud automates this |
| Upgrade path | Stop, upgrade and restart one instance | Rolling upgrades across nodes; confirm the procedure for your release with Qdrant docs |
| Operating effort | Single service, backups via snapshots | Node monitoring, shard planning, manual rebalancing and backup per node |
How the cluster pieces fit together
A self-hosted Qdrant cluster is a set of decisions that depend on each other: how the nodes agree, how data is split, how many copies you keep, and what storage each node needs. Read the cards in order, because the shard count and replication factor you choose at collection creation are hard to change later.
Enable cluster mode deliberately
Distributed mode is off until you turn it on, either in the configuration file or with the environment variable QDRANT__CLUSTER__ENABLED=true. Every node in the cluster must run with it enabled before it can join the others. Check this in your deployment template first, since a node started without it runs as a standalone instance and will not take part in the cluster you planned.
Raft keeps topology consistent
Qdrant uses the Raft consensus protocol to agree on the cluster topology and on collection structure, such as which collections exist and how they are laid out. Raft governs this metadata, not every vector write. Plan for a leader election to pause metadata changes during node failures, and test how your client handles a brief window of rejected schema operations.
Collections split into shards
Each collection is divided into shards that are spread across the nodes, so no single machine holds all the vectors. The shard count must be a multiple of the node count. The Qdrant docs recommend at least 2 shards per node so you can add nodes later, and suggest 12 shards for significant growth so a collection can expand to 2, 3, 6 and 12 nodes. Shard count is set at creation, so decide it before loading data.
Replication factor doubles storage
The replication factor sets how many copies of each shard the cluster keeps. It defaults to 1, which means no extra copy, so a lost node loses data for its shards. A factor of 2 doubles the storage footprint. For self-hosted Qdrant, changing the replication factor after the collection is created has no effect, so set it deliberately at creation and size disks for the copies you choose.
Block storage only, no NFS or S3
Each node needs block-level storage with a POSIX-compatible file system. Qdrant cannot run on network file systems such as NFS or on object storage such as S3. SSD or NVMe drives are recommended. When you size nodes in your cloud account or data center, confirm with your storage team that the volumes meet these requirements, and test disk latency under your expected write load.
Three nodes for quorum
The Qdrant docs recommend at least three nodes for production clusters so that quorum survives a node failure. A two-node cluster cannot lose a member and still reach a majority, which makes it a poor target for high availability. Budget for three nodes, plus the shard and replica copies they hold, before you commit to a cluster design. Ask your infrastructure team to confirm the failure domains of those nodes.
What moving from one node to a cluster involves
The sequence turns a single Qdrant node into a cluster with a known topology, collections sized for growth and a snapshot you can restore if a change goes wrong. Each step ends with a check you can record before moving on.
Confirm storage on every node
The platform or storage engineer checks that each node that will join the cluster has block-level storage with a POSIX-compatible file system, ideally on SSD or NVMe drives. Qdrant cannot run on network file systems such as NFS or on object storage such as S3, so an NFS mount or S3 bucket fails this check even if the node itself is healthy. Mark the step complete when every node reports the expected file system and device type and you have recorded the results alongside the node inventory.
Snapshot the single node first
Before you change anything, the database owner takes a snapshot of every collection on the existing node using the Qdrant snapshot documentation. Keep the snapshot files outside the node you are about to reconfigure so a failed change does not take the backup with it. The step is done when each collection's snapshot is listed, its size looks plausible for the data on disk, and a restore has been tested on a separate instance. The migration tool is another documented option if you are moving data to a new cluster rather than expanding the existing one.
Enable cluster mode on each node
The platform engineer sets distributed mode on every node, either in the configuration file or with the environment variable QDRANT__CLUSTER__ENABLED=true, and applies the same networking and TLS settings across nodes. Cluster peers must be able to reach each other on the internal ports Qdrant uses, and API access should be restricted before any node is exposed, because Qdrant instances are not secure by default. The step is complete when each node starts in cluster mode and reports its cluster status without errors in its logs.
Form the cluster on three or more nodes
The platform engineer joins the nodes into one cluster using the bootstrap and peer settings in the distributed deployment docs for the version in use. Qdrant uses Raft consensus to keep cluster topology and collection structure consistent, and the docs recommend at least three nodes for production so quorum survives a node failure. The step is done when the cluster reports all expected peers as healthy and a leader is elected. Confirm the exact join procedure against the distributed deployment documentation for your version before you run it.
Plan shard count and replication factor
The architect chooses a shard count that is a multiple of the node count and sets the replication factor when each collection is created, since the docs say changing it later has no effect on self-hosted Qdrant. The docs recommend at least two shards per node so you can expand without resharding, and suggest 12 shards for significant growth so the collection can later span 2, 3, 6 or 12 nodes. Note that a replication factor of 2 doubles storage, and the default of 1 keeps no extra copy. The step is complete when the sizing decision is written down with the expected data volume and growth path.
Create collections and load data
The database owner creates each collection with the shard count and replication factor from the plan, then loads data and checks that points are spread across shards rather than concentrated on one node. Because self-hosted clusters do not rebalance shards automatically, an uneven spread must be corrected by hand using the manual balancing procedures in the docs. The step is done when the per-shard point counts are recorded and the distribution is acceptable for your query load.
Verify consistency and failover
The QA or operations engineer runs test queries against each node and compares results with the single-node baseline, then stops one node in a test environment to confirm that the cluster still answers queries and that the replicas behave as expected. Check that API keys, read-only keys and any JWT-based access rules still apply on every node. The step is complete when query results match the baseline and the failover test is written up with its observed behavior.
Take a post-change snapshot and document
The database owner takes a new snapshot of the cluster collections and stores it with the earlier one, then the team documents the topology, shard layout, replication factor and the version used. Recheck the exact steps against the installation and distributed deployment docs for the release you run, since commands and settings change between versions. The step is done when the snapshot restores successfully in a test environment and the runbook is approved by the team that will operate the cluster.
Who does the rebalancing, upgrades and backups
This table compares who carries day-two work for a single self-hosted Qdrant node and a self-hosted distributed cluster, and what the cluster adds on top. Read each row as a question to ask your team: if the answer is "we do it by hand," budget the engineering time before choosing the cluster. The main takeaway is that moving to a self-hosted cluster does not remove operations work; it moves the balancing, upgrade ordering and security configuration onto your staff.
| Area | Option A: single node | Option B: self-hosted cluster |
|---|---|---|
| Shard rebalancing | Not applicable, all shards live on one node | Manual. Self-hosted clusters do not rebalance shards automatically, so your team moves shards when nodes are added or removed |
| Resharding | Not applicable at the cluster level | Manual. Automatic resharding is a Qdrant Cloud feature as of v1.13.0; plan shard counts up front (a multiple of the node count) |
| Upgrades | Stop, upgrade and restart one process; plan a maintenance window | Rolling upgrades are your procedure to design and test. The community Helm chart lacks zero-downtime upgrades, which are an enterprise feature |
| Backups with snapshots | Snapshot the collections and copy them off-host on your schedule | Snapshot per collection and per node, and test restores. Snapshots are not a substitute for a tested cluster recovery plan |
| Monitoring | Watch one node's memory, disk and search latency | Also watch Raft state, shard health, replica sync and uneven shard load across nodes |
| Replication factor | Default of 1 means no extra copy; no redundancy | Set at collection creation. Factor 2 doubles storage, and changing it later does nothing on self-hosted Qdrant |
| Security configuration | Set API keys and TLS yourself; by default the instance has no authentication and listens on all interfaces | Same controls on every node and between nodes. JWT per-collection access control arrived in v1.9.0 and JSON audit logging in v1.17.0 |
| Skills required | Linux operations, storage sizing and basic API security | Distributed systems operations: consensus, quorum, shard placement and rolling change procedures, plus the skills above |
When a managed or enterprise path changes the calculation
Self-hosted Qdrant leaves shard balancing, resharding and cluster upkeep with your team. The four paths below move some or all of that work to Qdrant or to a Kubernetes chart you run yourself, and each one carries different costs, control and support terms.
Qdrant Cloud managed clusters
Qdrant Cloud rebalances shards automatically and offers resharding as of v1.13.0, which removes the manual balancing that a self-hosted cluster requires. This fits teams that want a distributed collection without running Raft membership, shard moves and upgrades themselves. Check the data residency terms, the uptime tier you need (the Standard tier lists a 99.5% uptime SLA and Premium lists 99.9%), and whether your corpus can leave your environment at all.
Qdrant Hybrid Cloud on your infrastructure
Hybrid Cloud runs managed Qdrant clusters on infrastructure you control, so the operational model is closer to Cloud while data stays in your accounts. It suits organizations that need managed rebalancing but cannot place vectors with a third party. Pricing is set through Qdrant sales, with no figures published on the pricing page, so ask for a written scope that lists what Qdrant operates and what your team still owns.
Qdrant Private Cloud with the enterprise operator
Private Cloud is a dedicated, fully isolated enterprise deployment, and Qdrant documents an enterprise Kubernetes operator as part of it. The operator is the route to zero-downtime upgrades and automatic shard rebalancing without handing data to a shared service. Pricing is through Qdrant sales with no figures given, so confirm in writing which upgrade, backup and rebalancing duties sit with Qdrant and which stay with your platform team.
Community Helm chart for self-run Kubernetes
Qdrant's community-supported Helm chart lets a platform team run distributed Qdrant on Kubernetes without an enterprise contract. The chart does not include zero-downtime upgrades or automatic shard rebalancing, so your team keeps the shard count, replication factor and rebalancing work. It fits teams with strong Kubernetes operations and an acceptable support model. Confirm storage classes provide block-level, POSIX-compatible volumes, since network file systems and object storage are not supported.
What do buyers ask before moving Qdrant to a cluster?
How much more effort is a self-hosted Qdrant cluster than a single node?
A single node needs one server, one storage volume and an API key configuration. A self-hosted cluster adds a set of nodes that must agree on topology through the Raft consensus protocol, plus decisions about shard count and replication factor that you cannot easily change later. The distributed deployment docs recommend at least three nodes for production so quorum survives a node failure, and the shard count must be a multiple of the node count. Each node also needs block storage with a POSIX-compatible file system, since Qdrant cannot run on NFS or S3, and SSD or NVMe drives are recommended. Expect extra work in monitoring every node, testing failover and handling upgrades, because the cluster must stay consistent across all of them.
Can an in-house platform team run a self-hosted Qdrant cluster without outside help?
Often yes, if the team already runs stateful services on Kubernetes or bare metal and can own storage, backups and upgrades. The gaps to check are shard planning, manual rebalancing and resharding, which the self-hosted docs say are not automatic, and secure defaults. By default self-deployed instances listen on all interfaces with no authentication, so the team must configure admin and read-only API keys, TLS and JWT-based access control before production. Confirm your team can do this with its own staff, and decide whether it has the time to rehearse node failure and recovery before go-live. Independent help can be scoped in writing if any of these areas are new to the team.
What drives the cost of a self-hosted Qdrant cluster?
Cost comes from four components: the nodes you run, the storage each node needs, the replicas you keep, and the staff time to operate the cluster. The replication factor defaults to 1, meaning no extra copy, and a factor of 2 doubles storage, so the replica choice is the largest driver of disk spend. Node count rises with the shard plan, since the docs suggest 12 shards for significant growth so a collection can expand to 2, 3, 6 and 12 nodes. Staff time grows with the number of nodes you must patch, monitor and rebalance by hand. The open-source engine is free to self-host under Apache-2.0, so the license is not the main cost; infrastructure and labor are.
Which cluster costs are one-time and which recur?
One-time costs usually include architecture and shard planning, initial deployment, security hardening, migration of collections and the first round of failover testing. Recurring costs include the nodes and storage you keep running, the replicas that multiply storage, monitoring, patching, upgrades, backups and the ongoing manual balancing work. Scaling out later is also recurring in practice, because adding nodes means redistributing shards by hand. Ask a vendor or partner to split their quote into these two groups so you can compare the first year with later years.
What should I ask for in a quote for a self-hosted Qdrant cluster?
Ask for the written scope before any figure: node count and sizing, storage type, shard count and replication factor with the reasoning behind them, and the authentication and TLS configuration. Request the deliverables in writing, such as a runbook for manual rebalancing and resharding, failover test results and backup procedures using Qdrant snapshots. Ask how upgrades will be handled and whether ongoing support is a separate retainer. Confirm which environment is in scope, whether it runs in your cloud, data center or air-gapped network, and who holds the cluster credentials after handover. Most engagements are fixed-scope, so the quote should follow from the agreed scope rather than a generic package.
How long does it take to move from one node to a cluster?
The duration depends on the scope, the data volume, the number of nodes, the security requirements and how much of the environment is already built, so no single timeline applies. Confirm the timeline with the vendor or partner against your written scope, and ask them to list the phases, including design, build, migration, failover testing and handover. Pay attention to the test phase, since failover and recovery rehearsals usually take longer than the initial setup. Do not rely on a timeline that is not tied to a defined scope.
Does a managed Qdrant option remove the rebalancing work?
Qdrant Cloud rebalances shards automatically and offers resharding as of v1.13.0, which removes the manual balancing that self-hosted clusters must perform. The managed tiers also include features such as zero-downtime upgrades, which the Helm chart lacks. Qdrant Hybrid Cloud runs managed clusters on your own infrastructure, and Qdrant Private Cloud is a dedicated enterprise deployment; both are priced through Qdrant sales. Weigh these against the cost of running the cluster yourself, and confirm with Qdrant which features apply to your tier and deployment model before deciding.
Why security settings come before the first cluster node
Configure security on every Qdrant node before any cluster traffic flows, because a self-deployed instance is open by default. The Qdrant security documentation states that all self-deployed instances listen on all network interfaces and have no authentication configured. A node that joins a cluster with those defaults exposes its REST and gRPC endpoints to anything that can reach its network, and the same gap repeats on every node you add. Treat the hardening checklist as part of the cluster build, not a follow-up task after the first successful query.
Start with the controls that apply to every node. Set an admin API key and a read-only API key so that routine clients never hold write rights, enable TLS for REST and gRPC, and restrict network access so that only other cluster members, your application services and your administrators can reach the ports. Qdrant has supported API keys and TLS since v1.2.0, so confirm the exact configuration keys and their behavior for the version you deploy in the Qdrant security documentation before you copy any example into a production file. Verify the settings with a test request from a host that should be blocked.
If several applications share one cluster, add JWT-based access control with per-collection read or write permissions, which Qdrant introduced in v1.9.0. Turn on JSON audit logging of authenticated API operations, introduced in v1.17.0, and confirm where those logs are written and how long your team retains them. Ask your security team to review these controls against your own policy, and confirm each one on the exact release you plan to run, since the documentation for your version is the authority on what is supported.
How DeployOpen scopes and runs a Qdrant deployment
DeployOpen starts from your data volume, query load, availability target and team skills, then sets out in writing whether one Qdrant node or a cluster fits the work. The engagement covers planning, installation inside your own infrastructure, testing, documentation and handover, with ongoing support available as a retainer.
How we scope
- The written scope states whether the work is a single node, a new cluster or a move from one to the other.
- Scope lists collections, expected growth, shard count, replication factor and the failure cases the cluster must survive.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before any build work starts.
How we build
- Storage is provisioned on block-level, POSIX-compatible disks because Qdrant does not run on NFS or S3-style object storage.
- Cluster mode is enabled, nodes are joined, and the shard and replication layout is set before collections are created.
- Access is locked down with API keys, TLS and per-collection permissions, since default self-deployed instances have no authentication.
How we hand over
- Testing covers node failure, restart, snapshot restore and a manual shard rebalance, with results recorded in the handover pack.
- Runbooks document how to add a node, rebalance shards by hand and reconfigure replication for your environment.
- Documentation lists the versions deployed, configuration keys used and the upgrade steps your team will follow.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the build.
- Retainer scope should name who performs manual shard rebalancing and who reviews each Qdrant release before upgrade.
- Ask any provider to confirm in writing how they will handle rebalancing and resharding that the managed service would automate.
