/vertical-scaling

name: qdrant-vertical-scaling
description: "Guides Qdrant vertical scaling decisions. Use when someone asks 'how to scale up a node', 'need more RAM', 'upgrade node size', 'vertical scaling', 'resize cluster', 'scale up vs scale out', or when memory/CPU is insufficient on current nodes. Also use when someone wants to avoid the complexity of horizontal scaling."

What to Do When Qdrant Needs to Scale Vertically

Vertical scaling means increasing CPU, RAM, or disk on existing nodes rather than adding more nodes. This is the recommended first step before considering horizontal scaling. Vertical scaling is simpler and avoids distributed system complexity.

• Vertical scaling for Qdrant Cloud is done through the [Qdrant Cloud Console](https://cloud.qdrant.io/)
• For self-hosted deployments, resize the underlying VM or container resources

When to Scale Vertically

Use when: current node resources (RAM, CPU, disk) are insufficient, but the workload doesn't yet require distribution.

• RAM usage approaching 80% of available memory (OS page cache eviction starts, severe performance degradation)
• CPU saturation during query serving or indexing
• Disk space running low for on-disk vectors and payloads
• A single node can handle up to ~100M vectors depending on dimensions and quantization
• For non-production workloads, which are tolerant to single-point-of-failure and don't require high availability

How to Scale Vertically in Qdrant Cloud

• Resize in the [Qdrant Cloud Console](https://cloud.qdrant.io/) or with the [CLI tool](https://github.com/qdrant/qcloud-cli). Every node in the cluster is scaled to the same size [Vertical scaling](https://skills.qdrant.tech/md/documentation/cloud/cluster-scaling/?s=vertical-scaling)
• The upgrade process involves a rolling restart with no downtime if replication is configured
• Ensure `replication_factor: 2` or higher before resizing to maintain availability during the rolling restart

**Important:** Scaling up is straightforward. Scaling down requires care -- if the working set no longer fits in RAM after downsizing, performance will degrade severely due to cache eviction. Always load test before scaling down.

RAM Sizing Guidelines

• Estimate RAM per component (vectors, HNSW index, ID tracker, payload indexes) for the structures you keep in RAM, using the formulas in [Capacity planning](https://skills.qdrant.tech/md/documentation/capacity-planning/?s=calculating-ram-and-disk-size). For a full sizing walkthrough, see [qdrant-sizing](../../../qdrant-sizing/SKILL.md)
• Quantization adds a compressed copy alongside the original vectors. RAM for vectors drops only when the originals move to disk (`memory: cold`) and the quantized copy stays in RAM. With scalar quantization, the copy is 1/4 the size (INT8 reduces each float32 to 1 byte) [Quantization](https://skills.qdrant.tech/md/documentation/manage-data/quantization/)
• With binary quantization, the copy is 1/32 the size [Binary quantization](https://skills.qdrant.tech/md/documentation/manage-data/quantization/?s=binary-quantization)
• On Qdrant 1.19 or newer, the TurboQuant datatypes shrink vectors on their own, without separate quantization: `turbo4` by ~8x (1.19+), `turbo8` by ~4x and `turbo16` by ~2x (both 1.20+, higher recall). They apply to dense vectors and multivectors [Vector datatypes](https://skills.qdrant.tech/md/documentation/manage-data/vectors/?s=datatypes)
• On Qdrant 1.20 or newer, the ID tracker can move to `cached` or `cold` memory tiers (previously always resident), which frees RAM at very high point counts [Memory tiers](https://skills.qdrant.tech/md/documentation/ops-configuration/memory-tiers/)
• Add overhead for the HNSW index (about 150 bytes per point at the default `m: 16`) and payload indexes; the WAL counts against disk, not RAM [Capacity planning](https://skills.qdrant.tech/md/documentation/capacity-planning/)
• Reserve 20% headroom for optimizer operations and OS cache
• Monitor actual usage via Grafana/Prometheus before and after resizing [Monitoring](../../../qdrant-monitoring/SKILL.md)

When Vertical Scaling Is No Longer Enough

Recognize these signals that it's time to go horizontal:

• Data volume exceeds what a single node can hold even with quantization and mmap
• IOPS are saturated (more nodes = more independent disk I/O)
• Need fault tolerance (requires replication across nodes)
• Need tenant isolation via dedicated shards
• Single-node CPU is maxed and query latency is unacceptable
• Next vertical scaling step is the largest available node size. You might need to be able to temporarily scale up to the larger node size to do batch operations or recovery. If you are already at the largest node size, you won't be able to do that.

When you hit these limits, see [Horizontal Scaling](../horizontal-scaling/SKILL.md) for guidance on sharding and node planning.

What NOT to Do

• Do not scale down RAM without load testing first (cache eviction = severe latency degradation that can last days)
• Do not ignore the 80% RAM threshold (performance cliff, not gradual degradation)
• Do not skip replication before resizing in Cloud (rolling restart without replicas = downtime)
• Do not jump to horizontal scaling before exhausting vertical options (adds permanent operational complexity)
• Do not assume more CPU always helps (IOPS-bound workloads won't improve with more cores)