How Much RAM Does a Vector Database Like Qdrant Need?

When you size a Qdrant server, the number of vectors alone does not tell you how much RAM to buy. RAM use depends on each vector’s dimensions and the data type of its values, as well as how many copies Qdrant stores. The indexes and payload fields you use also affect the estimate, along with whether Qdrant keeps data in memory or reads it from disk.

Qdrant can run with less RAM than it needs to keep all vectors and indexes in memory for fast searches. When a search needs data from disk, the disk reads slow the query. To estimate RAM, start with the collection’s configuration, add memory for indexes and other structures, then leave room for the operating system and temporary work.

Start with vector storage, then add indexes

For dense vectors, which store a value for each dimension, calculate the raw storage first:

number of points × replication factor × dimensions × bytes per dimension

A point is a database record that holds a vector and may also hold other fields. The replication factor is the number of stored copies of each point. Qdrant’s documented sizes are 4 bytes per dimension for float32, 2 for float16, 1 for uint8, and 0.5 for turbo4. If a point contains multiple named vectors, calculate storage for each vector separately and add the results. Qdrant lists these data types in its installation requirements.

Vector storage is only part of the estimate. Qdrant also needs RAM for the HNSW index, a graph that helps it find nearby vectors without comparing every point. It also uses memory for point IDs, payload data and indexes, and any compressed vectors or sparse-vector indexes in the collection. Payloads are extra fields stored with points, such as categories or timestamps. An index on a payload field uses extra memory to speed up filtering.

As a reference, Qdrant estimates that one million 768-dimensional float32 points with two stored copies need about 7.33 GB. The estimate assumes vectors and the HNSW index are cached, payloads are cold and have no indexes, and the vectors are not compressed through quantization. It includes 20% headroom:

These figures come from Qdrant’s capacity-planning example. They are a reference for this particular workload, not a universal RAM requirement for one million points. Payload indexes, additional vectors, and different memory settings change the total. The cluster must store all replicas, but each node’s RAM requirement depends on how Qdrant distributes the copies and shards across nodes.

Disk-backed data still uses RAM

Qdrant’s memory tiers describe how it handles collection data. Pinned data stays in the heap memory Qdrant manages and is not evicted. Cached data is mapped to files and loaded into the operating system’s page cache. The page cache keeps recently used file data in RAM and can evict it when memory is scarce. Cold data is mapped to files but not loaded in advance. When Qdrant accesses it, the operating system reads the needed pages from disk and can then keep them in the cache.

By default, Qdrant puts dense vectors and the HNSW index in the cached tier, payloads in the cold tier, and payload indexes and the ID tracker in the pinned tier, according to its documented defaults. So saying that vectors are stored “on disk” does not tell you how much RAM they use. RAM use also depends on the memory tier and how much data the operating system keeps in its cache. Qdrant explains these behaviors in its memory-tier documentation.

When Qdrant puts vectors in the cold tier, it does not need to keep the entire vector set in RAM in advance. Searches that need uncached pages must read them from disk. The HNSW index is especially sensitive to this choice. As Qdrant follows the graph, it makes many small reads from different locations, and disk latency can slow those reads substantially. You can reduce RAM use while keeping index access faster by caching the index and placing vectors in a colder tier.

Quantization reduces vector memory, with a quality trade-off

Quantization compresses vectors to use less storage. In Qdrant’s example, keeping 4-bit TurboQuant vectors pinned in the same collection of one million 768-dimensional points with two replicas uses an estimated 0.72 GB for the compressed vectors, compared with 5.72 GB for the original dense vectors. These figures cover vector storage only. The index, ID tracker, payload indexes, and headroom still need RAM.

Qdrant recommends testing search recall on the collection’s own data against results from unquantized vectors. Recall measures how many expected nearest results each search returns. If Qdrant keeps the original vectors cold and uses compressed vectors for search, rescoring candidates against the originals requires disk access. The capacity-planning guidance describes both the memory reduction and these trade-offs.

More RAM usually buys faster access

A Qdrant benchmark published in December 2022 shows the trade-off between RAM use and query speed. In its test with one million 100-dimensional GloVe vectors, an in-memory configuration handled about 780 requests per second when the memory limit was 1.2 GB or more. Another configuration mapped both vectors and the HNSW graph to files and used 135 MB, but handled only 0.33 requests per second, or about three seconds per query. Qdrant reported the results in its memory-consumption benchmark.

Use those numbers as an illustration, not as a current sizing target. The benchmark used one dataset and environment and did not identify the exact Qdrant version. Its results do not establish performance for other workloads. A low-RAM configuration can run while making searches too slow. Choose RAM based on the latency your searches need, then test with representative queries and data.

Leave room for node overhead and validate the estimate

Qdrant recommends adding about 20% headroom to account for the operating system’s page cache. The headroom also covers runtime overhead and temporary optimization work. It also advises keeping node usage below roughly 80% of physical RAM. Treat these as planning rules and check whether your workload meets its latency target. Qdrant’s Cloud sizing guidance gives a separate broad estimate: the HNSW index typically adds 20% to 30% to vector memory. The detailed capacity example instead estimates 0.29 GB for the HNSW index alongside 5.72 GB for vectors. The documentation does not explain how the figures relate, so they are not interchangeable guarantees.

Qdrant’s memory-usage monitoring breaks down memory by collection component and distinguishes heap RAM that Qdrant cannot evict from file pages cached by the operating system. Qdrant says these figures are estimates and do not include some memory used by third-party libraries and allocators. Tools such as top can also make process memory hard to interpret when Qdrant uses mapped files and the disk cache. Qdrant explains these limits in its memory-usage documentation and database optimization FAQ.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com