עב
עב

RAG vector database sizer: RAM and disk

Enter how many chunks you embed, the embedding model, the index and the quantization. You get the RAM and the disk the vector database needs as a range, with every structure counted and every factor linked to the documentation it comes from.

Data
One vector per chunk: documents × chunks per document. A 1,000-token chunk is about 4 KB of English text.
The dimension comes from the provider's documentation. Pick another model to type it.

Dimension of text-embedding-3-small: the provider's documentation (2026-10-16)

The length of the vectors your model outputs. Models that allow shorter output (Matryoshka) use what you request.
Metadata and the chunk's text if you store it with the vector. 0 when the text lives elsewhere.
Index and storage
16 is Qdrant's default. More links raise recall and memory; the bottom layer keeps m × 2 links a vector.
int8 and binary keep a compressed copy in RAM and the float32 originals on disk for rescoring.
Copies of every vector across the cluster. 1 for a single node; 2 or more for high availability.

Result

RAM
5.91 GiB to 7.1 GiB
Disk
7.34 GiB to 8.81 GiB
RAM per vector, one copy
6,349.6 B
Breakdown
LineValueAssumptions used
Vectors (RAM and disk)5.72 GiB
  • Bytes per dimension, float32
HNSW graph (RAM and disk)146.48 MiB
  • Bytes per HNSW link
  • HNSW upper layers and bookkeeping
ID tracker (RAM and disk)49.59 MiB
  • ID tracker per point
Payload (disk)1.43 GiB
  • Payload storage overhead
RAM before headroom5.91 GiB
  • Bytes per dimension, float32
  • Bytes per HNSW link
  • HNSW upper layers and bookkeeping
  • ID tracker per point
Disk before headroom7.34 GiB
  • Bytes per dimension, float32
  • Bytes per HNSW link
  • HNSW upper layers and bookkeeping
  • ID tracker per point
  • Payload storage overhead

Calculator vector-db 1.0.0 · engine @anaroq/calc 1.4.0 · data snapshot 2026.10.4 · How the calculators work

Assumptions

Every number the result uses that you didn't enter. Change any of them to match your case.

  • Bytes per dimension, float32
    4 B (Fixed definition)

    A float32 component is 4 bytes: Qdrant's default vector datatype.

    Source ·
  • Bytes per HNSW link
    4 B (Fixed definition)

    Each link of the graph is a 4-byte point id; the bottom layer has m × 2 links a point.

    Source ·

  • Qdrant's factor on the bottom layer's links for the upper layers and bookkeeping.

    Source ·
  • ID tracker per point
    52 B (Fixed definition)

    Qdrant keeps 52 bytes a point that map ids to internal offsets, resident in RAM at all times.

    Source ·

  • Qdrant's factor on the raw payload for its storage backend. Payload stays on disk (the cold tier, Qdrant's default).

    Source ·
  • %

    Added to the RAM and disk totals for the page cache, runtime and optimizer (RAM) and the WAL, snapshots and temporary segments (disk). The top of each range.

    Source ·

What you enter and the assumptions you change are kept in this page's link, after the #.

Take the result with you

The result as a Markdown file: what you entered, the breakdown, every factor with its source and the link that reproduces it.

vector-db-size.md
# RAG vector database sizer: RAM and disk

An estimate from the assumptions listed below, not a measurement or a guarantee.

## What you entered

- Vectors (chunks): 1,000,000
- Embedding model: OpenAI text-embedding-3-small (https://developers.openai.com/api/docs/guides/embeddings)
- Dimensions: 1,536
- Index: HNSW (graph)
- HNSW links per node (m): 16
- Vector storage: float32 (no quantization)
- Average payload per vector (bytes): 1,024
- Replication factor: 1

## Result

- RAM: 5.91 GiB to 7.1 GiB
- Disk: 7.34 GiB to 8.81 GiB
- RAM per vector, one copy: 6,349.6 B

## Breakdown

| Line | Value | Assumptions used |
| --- | --- | --- |
| Vectors (RAM and disk) | 5.72 GiB | Bytes per dimension, float32 |
| HNSW graph (RAM and disk) | 146.48 MiB | Bytes per HNSW link, HNSW upper layers and bookkeeping |
| ID tracker (RAM and disk) | 49.59 MiB | ID tracker per point |
| Payload (disk) | 1.43 GiB | Payload storage overhead |
| RAM before headroom | 5.91 GiB | Bytes per dimension, float32, Bytes per HNSW link, HNSW upper layers and bookkeeping, ID tracker per point |
| Disk before headroom | 7.34 GiB | Bytes per dimension, float32, Bytes per HNSW link, HNSW upper layers and bookkeeping, ID tracker per point, Payload storage overhead |

## Assumptions

- Bytes per dimension, float32: 4 B. A float32 component is 4 bytes: Qdrant's default vector datatype. Source: https://qdrant.tech/documentation/capacity-planning/ (read 16 Oct 2026)
- Bytes per HNSW link: 4 B. Each link of the graph is a 4-byte point id; the bottom layer has m × 2 links a point. Source: https://qdrant.tech/documentation/capacity-planning/ (read 16 Oct 2026)
- HNSW upper layers and bookkeeping: 1.2. Qdrant's factor on the bottom layer's links for the upper layers and bookkeeping. Source: https://qdrant.tech/documentation/capacity-planning/ (read 16 Oct 2026)
- ID tracker per point: 52 B. Qdrant keeps 52 bytes a point that map ids to internal offsets, resident in RAM at all times. Source: https://qdrant.tech/documentation/capacity-planning/ (read 16 Oct 2026)
- Payload storage overhead: 1.5. Qdrant's factor on the raw payload for its storage backend. Payload stays on disk (the cold tier, Qdrant's default). Source: https://qdrant.tech/documentation/capacity-planning/ (read 16 Oct 2026)
- Headroom: 20%. Added to the RAM and disk totals for the page cache, runtime and optimizer (RAM) and the WAL, snapshots and temporary segments (disk). The top of each range. Source: https://qdrant.tech/documentation/capacity-planning/ (read 16 Oct 2026)

Calculator vector-db 1.0.0 · engine @anaroq/calc 1.4.0 · data snapshot 2026.10.4

Open this calculation: https://anaroq.com/tools/vector-db-sizer#k=eyJhc3N1bXB0aW9ucyI6e30sImNhbGMiOiJ2ZWN0b3ItZGIiLCJpbnB1dCI6eyJkaW1lbnNpb25zIjoxNTM2LCJobnN3TSI6MTYsImluZGV4IjoiaG5zdyIsIm1vZGVsIjoib3BlbmFpLXRleHQtZW1iZWRkaW5nLTMtc21hbGwiLCJwYXlsb2FkQnl0ZXMiOjEwMjQsInF1YW50aXphdGlvbiI6ImZsb2F0MzIiLCJyZXBsaWNhcyI6MSwidmVjdG9ycyI6MTAwMDAwMH0sInYiOjF9
How the calculators work: https://anaroq.com/methodology#calculators

What it does

It adds up every structure a vector database keeps for your vectors: the vectors themselves, the index, the ID tracker and the payload, multiplied by the replication factor, and states what must be in RAM and what goes to disk. The method is Qdrant's published capacity planning, term by term; FAISS and Milvus documentation give the IVF terms.

How it works

  1. Base: vectors × replication factor, because every copy holds every vector.
  2. Vectors: base × dimensions × bytes per dimension (float32 4, float16 2). With int8 (1 byte) or binary (1 bit) quantization the compressed copy is what RAM holds, and the float32 originals stay on disk for rescoring.
  3. Index: HNSW stores base × m × 2 links × 4 bytes × 1.2 for its upper layers. IVF stores an 8-byte id per vector and one float32 centroid per cluster. Flat stores nothing extra and searches every vector.
  4. ID tracker: 52 bytes a vector, always in RAM. Payload: base × average payload × 1.5, on disk.
  5. RAM = vectors in RAM + index + ID tracker. Disk = every structure. Each range runs from that sum to the sum plus 20% headroom for the page cache, the optimizer, the write-ahead log and snapshots. Sizes are binary: 1 GiB = 2³⁰ bytes.
  6. Every factor is listed under Assumptions with the documentation page it comes from; the overhead factors and the headroom can be changed.

Example

1,000,000 chunks embedded with OpenAI text-embedding-3-small (1536 dimensions), HNSW with m = 16, float32, 1 KiB of payload each and one copy:

1,000,000 vectors · 1536 dimensions · HNSW m 16 · float32 · 1 replica

RAM
5.91 GiB to 7.1 GiB
Disk
7.34 GiB to 8.81 GiB
RAM per vector, one copy
6,349.6 B

Limits

  • A sizing estimate, not a benchmark: it says nothing about query speed or recall, and it does not compare products.
  • The overhead factors are Qdrant's. Other databases differ: Weaviate counts 8 to 10 bytes per graph link and advises doubling the vector memory for Go's garbage collector, which lands above the top of this range.
  • Payload is counted on disk only (Qdrant's default cold tier). Payload you keep in RAM, payload indexes and sparse vectors are not included.
  • Quantized search with originals on disk is slower when it rescores; keep the originals in RAM if you need that speed, and count them as RAM.
  • No price. What a server or a managed database with this much RAM and disk costs is not part of this page.

Methodology: how the numbers are worked out

Sources

  1. ANAROQ calculator methodology: assumptions, units and rounding
  2. Qdrant Documentation: Capacity Planning
  3. Qdrant Documentation: Quantization
  4. FAISS wiki: Faiss indexes
  5. Milvus Documentation: IVF_FLAT
  6. Weaviate Documentation: Resource Planning

Updated

Next step

Qdrant

A free public tool by ANAROQ, a company building compute infrastructure. What ANAROQ is building