/memory-usage-optimization

name: qdrant-memory-usage-optimization
description: "Diagnoses and reduces Qdrant memory usage. Use when someone reports 'memory too high', 'RAM keeps growing', 'node crashed', 'out of memory', 'memory leak', or asks 'why is memory usage so high?', 'how to reduce RAM?'. Also use when memory doesn't match calculations, quantization didn't help, or nodes crash during recovery."

Understanding memory usage

Qdrant operates with two types of memory:

• Resident memory (aka RSSAnon) - memory used for internal data structures like the ID tracker, plus components that stay fully in RAM (the `pinned` tier), such as quantized vectors and payload indexes. On Qdrant 1.20 or newer, the ID tracker has its own `memory` tier and can leave resident memory; before 1.20 it was always resident.

• OS page cache - memory used for caching disk reads, which can be released when needed. Original vectors are normally stored in page cache, so the service won't crash if RAM is full, but performance may degrade. This is the `cached` and `cold` tiers. See the [default tiers](https://skills.qdrant.tech/md/documentation/ops-configuration/memory-tiers/?s=default-tiers) for each component, and the [legacy settings](https://skills.qdrant.tech/md/documentation/ops-configuration/memory-tiers/?s=legacy-settings) for Qdrant 1.18 or older.

It is normal for the OS page cache to occupy all available RAM, but if resident memory is above 80% of total RAM, it is a sign of a problem.

Memory usage monitoring

• Qdrant exposes process memory through the `/metrics` endpoint. See [Monitoring docs](https://skills.qdrant.tech/md/documentation/ops-monitoring/monitoring/).
• For a per-collection breakdown of RAM, page cache, and disk use by component, call `GET /collections/{collection_name}/memory` or open the Web UI's Memory tab (v1.18+) [Memory usage](https://skills.qdrant.tech/md/documentation/ops-monitoring/memory-usage/)

How much memory is needed for Qdrant?

Optimal memory usage depends on the use case.

• For regular search scenarios, general guidelines are provided in the [Capacity planning docs](https://skills.qdrant.tech/md/documentation/capacity-planning/).

For a detailed breakdown of memory usage at large scale, see [Large scale memory usage example](https://skills.qdrant.tech/md/documentation/tutorials-operations/large-scale-search/?s=memory-usage).

Count payload indexes and the HNSW graph, not just the vectors: [Calculating RAM and disk size](https://skills.qdrant.tech/md/documentation/capacity-planning/?s=calculating-ram-and-disk-size) lists every component.

Additionally, Qdrant requires some extra memory for optimizations. During optimization, optimized segments are fully loaded into RAM, so it is important to leave enough headroom. The larger `max_segment_size` is, the more headroom is needed.

When to put HNSW index on disk

Putting frequently used components (such as HNSW index) on disk might cause significant performance degradation. On Qdrant 1.19 or newer this is set with `memory: cold` in `hnsw_config`; on 1.18 or older with `hnsw_config.on_disk: true`. There are some scenarios, however, when it can be a good option:

• Deployments with low latency disks - local NVMe or similar.
• Multi-tenant deployments, where only a subset of tenants is frequently accessed, so that only a fraction of data & index is loaded in RAM at a time.
• For deployments with [inline storage](https://skills.qdrant.tech/md/documentation/ops-optimization/optimize/?s=inline-storage-in-hnsw-index) enabled. On Qdrant 1.20 or newer, inline storage keeps the original vectors only in the HNSW index file, so `hnsw_config.memory` decides their tier and `vectors.memory` is ignored for those segments. Unless quantization has its own explicit `memory`, quantized vectors are `cold` when the HNSW index is `cold` and `pinned` in any other tier, so set it explicitly (for example `pinned`) if the index is `cold` but you want the quantized vectors in RAM [Inline storage](https://skills.qdrant.tech/md/documentation/ops-configuration/memory-tiers/?s=inline-storage).

How to minimize memory footprint

The main challenge is to put on disk those parts of data, which are rarely accessed. Here are the main techniques to achieve that:

• Use quantization to store only compressed vectors in RAM. On Qdrant 1.20 or newer, 8-bit TurboQuant (`bits8`, 4x compression) is the recommended default over scalar quantization at the same compression (use scalar for the Manhattan metric), and it doesn't rescore by default, unlike `bits2`, `bits1_5`, and `bits1` [Quantization docs](https://skills.qdrant.tech/md/documentation/manage-data/quantization/)

• Use float16 or uint8 datatypes to reduce memory usage of vectors by 2x or 4x respectively, with some tradeoff in precision. `uint8` only makes sense for vectors already quantized to 0-255. On Qdrant 1.19 or newer, the TurboQuant datatypes replace the original vectors with a compressed form (dense vectors and multivectors, not sparse): `turbo4` (4 bits/dimension, ~8x, from 1.19), `turbo8` (~4x, closer to `float32` recall, from 1.20), and `turbo16` (~2x, from 1.20, closer to `float32` than `float16`). Any of them can be paired with 1-bit quantization for cheaper rescoring than pairing 1-bit quantization with full-precision vectors. A TurboQuant datatype is not TurboQuant quantization, which keeps the originals and adds a copy. Read more about vector datatypes in [documentation](https://skills.qdrant.tech/md/documentation/manage-data/vectors/?s=datatypes)

• Leverage Matryoshka Representation Learning (MRL) to store only small vectors in RAM while keeping large vectors on disk. Examples of how to use MRL with Qdrant Cloud inference: [MRL docs](https://skills.qdrant.tech/md/documentation/inference/matryoshka-models/?s=reduce-vector-dimensionality-with-matryoshka-models)

• For multi-tenant deployments with small tenants, vectors might be stored on disk because the same tenant's data is stored together [Mul