Scaling & Resilience on Qdrant - Vector Search Engine

Vertical Scaling

info@qdrant.tech (Andrey Vasnetsov) — Mon, 01 Jan 0001 00:00:00 +0000

Vertical Scaling

Vertical scaling means resizing CPU, RAM, or disk on an existing node. It’s simpler than horizontal scaling, avoids distributed system complexity, and is reversible, which makes it the recommended first step whenever a single node’s resources are the bottleneck.

When to Scale Vertically

Scale vertically when your current node resources are insufficient but your workload doesn’t yet require distribution:

RAM usage is approaching 80% of available memory. Beyond this threshold, the operating system starts evicting pages from cache, which causes a sharp performance drop rather than a gradual one.
CPU is saturated during query serving or indexing.
Disk space is running low for on-disk vectors and payloads.
Your workload is non-production or otherwise tolerant of a single point of failure.

A single node can typically hold up to about 100 million vectors, depending on vector dimensionality and whether quantization is enabled.

Horizontal Scaling

info@qdrant.tech (Andrey Vasnetsov) — Mon, 01 Jan 0001 00:00:00 +0000

Horizontal Scaling

Horizontal scaling means adding more nodes to a Qdrant cluster instead of making existing nodes bigger. It’s how Qdrant handles data that no longer fits on one node, and it’s also the mechanism underlying Qdrant’s fault tolerance. This page covers how it works under the hood: sharding, replication, Raft consensus, and consistency guarantees.

For what these mechanics buy you in terms of fault tolerance and failover, see Resilience. For the practical configuration steps, see Distributed Deployment.

Resilience

info@qdrant.tech (Andrey Vasnetsov) — Mon, 01 Jan 0001 00:00:00 +0000

Resilience

Qdrant’s fault tolerance is driven by replication and node count. Together, they control whether your data survives a node loss and whether your cluster keeps serving requests when one goes down.

Resilience covers three distinct aspects of a Qdrant cluster, and it’s worth keeping them separate since a cluster can have one without the others:

Availability for reading and writing data: whether search and write requests keep succeeding while a node is down. See Temporary Node Failure for exactly how differently-configured clusters behave when a node goes down.
Availability for cluster-wide operations: whether you can still create, edit, or delete collections while a node is down. This requires a majority of nodes to be healthy, regardless of replication factor. See How many Qdrant nodes should I run? for how this plays out at different cluster sizes.
Data integrity: whether your data survives the permanent loss of a node. This depends on replication factor and node count together, not on either form of availability.

This page covers what determines Qdrant’s fault tolerance and how to configure failover in production. For how the underlying replication and consensus mechanics work, see Horizontal Scaling.

Distributed Deployment

info@qdrant.tech (Andrey Vasnetsov) — Mon, 01 Jan 0001 00:00:00 +0000

Distributed Deployment

Available since Qdrant v0.8.0

Qdrant supports a distributed deployment mode. In this mode, multiple Qdrant services communicate with each other to distribute the data across the peers to extend the storage capabilities and increase stability.

Enabling Distributed Mode in Self-Hosted Qdrant

To enable distributed deployment - enable the cluster mode in the configuration or using the ENV variable: QDRANT__CLUSTER__ENABLED=true.

cluster:
 # Use `enabled: true` to run Qdrant in distributed deployment mode
 enabled: true
 # Configuration of the inter-cluster communication
 p2p:
 # Port for internal communication between peers
 port: 6335

 # Configuration related to distributed consensus algorithm
 consensus:
 # How frequently peers should ping each other.
 # Setting this parameter to lower value will allow consensus
 # to detect disconnected node earlier, but too frequent
 # tick period may create significant network and CPU overhead.
 # We encourage you NOT to change this parameter unless you know what you are doing.
 tick_period_ms: 100

By default, Qdrant will use port 6335 for its internal communication. All peers should be accessible on this port from within the cluster, but make sure to isolate this port from outside access, as it might be used to perform write operations.

Consistency Guarantees

info@qdrant.tech (Andrey Vasnetsov) — Mon, 01 Jan 0001 00:00:00 +0000

Consistency Guarantees

By default, Qdrant focuses on availability and maximum throughput of search operations, which is a preferable trade-off for most use cases. During normal operation, you can search and modify data from any peer in the cluster: reads use a partial fan-out strategy to optimize latency and availability, and writes execute in parallel on all active sharded replicas.

This means concurrent updates on one point can result in an inconsistent state. For example, if two clients simultaneously update the same point in a collection with three replicas per shard. On some replicas, the point may reflect the update from one client, while on other replicas, the point may reflect the update from the other client.

Node Failure Recovery

info@qdrant.tech (Andrey Vasnetsov) — Mon, 01 Jan 0001 00:00:00 +0000

Node Failure Recovery

Sometimes hardware malfunctions might render some nodes of the Qdrant cluster unrecoverable. Several recovery scenarios allow Qdrant to stay available for requests and even avoid performance degradation. Let’s walk through them from best to worst.

Recover with Replicated Collection

If the number of failed nodes is less than the replication factor of the collection, then your cluster should still be able to perform read, search, and update queries.