Scaling & Resilience
When you get started with Qdrant, you typically deploy a single node: one server that stores your vectors and handles queries. That’s enough for most early-stage workloads, but as your dataset and traffic grow, you’ll need to scale. Qdrant gives you two options: give your node more resources (vertical scaling), or add more nodes to the cluster (horizontal scaling).
Horizontal scaling also provides resilience: deployments with multiple nodes and replicas remain available for reads and writes, even when individual nodes fail.
Vertical vs. Horizontal Scaling
Vertical scaling means adding more CPU, RAM, or disk to an existing node. A single node can typically hold up to about 100 million vectors, depending on dimensionality and quantization. RAM usage approaching 80% is the main signal that it’s time to resize. See Vertical Scaling for RAM sizing guidelines and resize steps for Qdrant Cloud and self-hosted deployments.
Qdrant can run in a distributed mode, where multiple nodes operate together as a single entity called a cluster. Horizontal scaling means adding more nodes to a cluster instead of resizing existing ones. It’s necessary when your data no longer fits on a single node even with quantization, or when you’re bottlenecked on disk I/O. See Horizontal Scaling to understand how distributed mode works, and Distributed Deployment for the configuration steps.
Scale vertically first: it’s simpler than distributing data across a cluster, avoids network overhead, and is easy to reverse. Move to horizontal scaling once vertical scaling isn’t enough. If you’re running in Qdrant Cloud, Scale Clusters covers the steps for both directions.
Resilience
Resilience comes from replicating data across multiple nodes. A single node, or a single copy of your data, has no protection against failure: if you lose it, you lose both the data and the ability to serve it. A minimal fault-tolerant cluster needs three nodes and a replication factor of two or higher. Three nodes are the minimum to form a majority for Qdrant’s Raft consensus, and two or more replicas ensure a single node failure won’t take your data or availability down with it.
See Resilience for how replication factor and node count determine fault tolerance and failover best practices.
When a node fails, the recovery path depends on whether the lost shards have replicas on surviving nodes. A node that restarts rejoins consensus and catches up automatically. A permanently lost node can be replaced by provisioning a new one and rebalancing shards. See Node Failure Recovery for step-by-step procedures.
Where to Go Next
- Vertical Scaling: resize existing nodes.
- Horizontal Scaling: how Qdrant’s distributed model achieves scale.
- Resilience: fault tolerance, multiple availability zones, and failover best practices.
- Consistency Guarantees: write consistency factor, read consistency, and write ordering.
- Node Failure Recovery: step-by-step procedures for recovering from a failed node.