# 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.

## How to Scale Vertically in Qdrant Cloud

Vertical scaling in Qdrant Cloud is managed through the [Cloud Console](https://cloud.qdrant.io/):

1. Select the cluster you want to resize.
2. Choose a larger node configuration, increasing CPU, RAM, or both.
3. Confirm the resize.

The resize runs as a rolling restart. If your collections have a replication factor of two or higher, the restart completes with no downtime, since other replicas keep serving traffic while each node restarts in turn. Set replication factor to two or higher before resizing if you need to avoid downtime.

Scaling up is generally safe. Scaling down needs more care: if your working set no longer fits in RAM after downsizing, performance degrades severely due to cache eviction. Load test before scaling down.

## How to Scale Vertically Self-Hosted

For self-hosted deployments, resize the underlying VM or container resources directly, then restart the affected nodes. If your collections have a replication factor of two or higher, you can resize nodes one at a time without downtime.

## RAM Sizing Guidelines

RAM is the resource that most directly affects Qdrant's search performance, since search is fastest when vectors and indexes fit in memory.

Exact RAM usage is difficult to predict precisely, but this formula gives a reasonable estimate for full-precision vectors kept in RAM:

```text
num_vectors * dimensions * 4 bytes * 1.5
```

Quantization can reduce this estimate by a factor of 4 to 32, depending on the quantization method.

On top of the vector data itself, budget for the HNSW index, which typically adds 20% to 30% overhead, along with payload indexes and the write-ahead log. Reserve about 20% headroom for optimizer operations and operating system cache.

See [Quantization](https://qdrant.tech/documentation/manage-data/quantization/index.md) for the tradeoffs between quantization methods, and monitor actual memory usage before and after resizing (see [Monitor Collection Memory Usage](https://qdrant.tech/documentation/ops-monitoring/memory-usage/index.md)).

## When Vertical Scaling Is No Longer Enough

These signals mean it's time to scale horizontally instead of resizing further:

- Your data volume exceeds what a single node can hold, even with quantization.
- CPU on your largest available node size is already maxed out with unacceptable query latency.
- Disk I/O is saturated. Adding nodes gives you more independent disk throughput.
- You need fault tolerance, which requires replicating data across nodes.

When you hit these limits, see [Horizontal Scaling](https://qdrant.tech/documentation/scaling/horizontal-scaling/index.md) and [Distributed Deployment](https://qdrant.tech/documentation/scaling/distributed_deployment/index.md) for how to scale out.

## Best Practices

- Load test before scaling down RAM. Cache eviction after downsizing can cause a latency regression.
- Keep RAM usage below 80%. Memory pressure in Qdrant causes a performance cliff, not a gradual slowdown.
- Set the replication factor to two or higher before resizing in Qdrant Cloud. A rolling restart without replicas causes downtime.
- Diagnose the bottleneck before adding CPU. Workloads bound on disk I/O won't improve from additional cores.