# Qdrant for RAG: deciding what belongs in RAM or on disk

Estimate Qdrant memory from vectors, graph structures, payload and replicas, then test RAM and on-disk placement against retrieval quality.

Author: Retrivium team
Updated: 2026-11-01
Canonical URL: https://retrivium.ai/journal/qdrant-memory-on-disk/
Language: en

Estimate Qdrant RAM from the collection's components rather than document count alone. Vectors, search structures, payload and auxiliary data consume resources differently. Placing data on disk changes the memory and latency profile; it does not make RAM consumption zero. Use a component estimate and verify it with a representative collection.

## Count vectors rather than source files

One document can create many chunks and therefore many vectors. Record vector count, dimension, representation and the embedding model. A collection of a thousand long documents can differ greatly from a thousand short records, even if both are described as the same document count.

For an illustrative 100,000 vectors with 768 float32 coordinates, raw values occupy `100000 × 768 × 4 = 307200000` bytes, about 293 MiB. This is arithmetic for coordinates, not a benchmark, full collection size or server-memory requirement. Keep decimal bytes and binary units explicit.

## Add other collection components

| Component | What belongs in the estimate |
| --- | --- |
| Vectors | Count, dimensions and representation |
| Search index | Structure and configured parameters |
| Payload | Stored fields, metadata and filter indexes |
| Replicas and service data | Actual deployment configuration |

Do not apply one universal overhead multiplier to every index and workload. Payload size can vary by record, while filter configuration can add its own structures. Record the actual schema and representative values before extrapolating from a small sample.

## Test RAM and SSD placement

Choose supported placement settings for the intended collection components and inspect their behavior. An on-disk configuration may use operating-system caches and other resident structures. Storage latency and workload access patterns become part of the result, so record SSD characteristics and query concurrency.

Compare a representative set of searches before and after changing placement. Include the filters used by the application rather than testing only an unfiltered nearest-neighbor request. A smaller resident footprint is useful only if retrieval quality and waiting time remain acceptable for the task.

## Observe actual usage and preserve quality

Qdrant documents component-level memory and disk observations. Compare them with process and operating-system measurements, recognizing that panels can treat page cache differently. Keep labels and units with the measurements instead of assuming every figure named RAM represents the same quantity.

Test ingestion, search, updates and restart on the sample collection. Extrapolate cautiously and reserve space for the complete service. An operations-funding discussion can then relate additional capacity to an observed index requirement rather than a generic database label.

Official references: [qdrant.tech — capacity planning](https://qdrant.tech/documentation/capacity-planning/), [qdrant.tech — memory usage](https://qdrant.tech/documentation/ops-monitoring/memory-usage/).

Related guides: [Embedding dimensions: calculating index memory](/journal/embedding-dimensions-memory/), [A local RAG server: placing components around the GPU](/journal/rag-server-local-architecture/).