Vector DB Size Calculator

How to use

1. Enter how many vectors you will store and their dimensions (the output size of your embedding model).
2. Choose the storage precision: float32, float16, int8 or binary (1 bit per dimension).
3. Choose index overhead: none (a flat index), HNSW with your M value, or a custom percentage. Add per-vector payload bytes if you store metadata.
4. Read RAM and disk. Tick “keep float32 originals on disk” if you re-score quantised results against full-precision vectors.

Worked example

One million 1,536-dimension embeddings. How big is the index at different settings?

Result

Per vector: 1,536 × 4 = 6,144 bytes (float32); HNSW adds M × 2 × 4 = 256 bytes; binary uses 1,536 ÷ 8 = 192 bytes.

How it works

Raw vector bytes = vectors × bytes per vector. A float32 dimension is 4 bytes, float16 is 2, int8 is 1, and binary quantisation keeps 1 bit per dimension, so a vector takes ⌈dimensions ÷ 8⌉ bytes.

HNSW overhead uses the estimate given in the Faiss wiki: memory is (d × 4 + M × 2 × 4) bytes per vector, so the graph links add M × 2 × 4 bytes per vector on top of the float32 vector. M (4 to 64 in the Faiss guidance) is the number of links per vector. The link cost does not depend on the vector precision.

The percentage mode is for other index types: it adds a chosen percentage of the vector bytes. We do not suggest a percentage, because it depends on the database, index type and settings; measure your own.

Disk = the same vectors and index + any per-vector payload you store + (optionally) the original float32 vectors, which some systems keep on disk so quantised search results can be re-scored. RAM is vectors + index overhead only.

Common errors

vectors must be a whole number of at least 1.

Enter a positive whole number; use the exact count, not a decimal.

dims must be a whole number from 1 to 100,000.

Use your embedding model’s output dimension, for example 768 or 1536.

hnswM must be a whole number from 1 to 1,024.

Common values are small (the Faiss guidance suggests 4 to 64).

overheadPercent must be between 0 and 1000.

Enter a percentage such as 20, not a fraction such as 0.2.

More than 1,000,000,000,000 vectors is not supported.

Check for an extra zero.

Limits

• These are payload-size estimates. Real databases also use memory for caches, write buffers, id maps, replicas and operating-system overhead. Multiply by your replica count yourself.
• The HNSW formula is the Faiss wiki’s estimate for a Faiss HNSW index; other systems (Qdrant, Milvus, pgvector, Elasticsearch) structure their indexes differently.
• Product quantisation, scalar-quantisation variants and compression of stored payloads are not modelled except through the custom percentage.
• Binary and int8 storage lose precision, which can reduce recall; this calculator measures size, not search quality.

Privacy

Only numbers are processed, in your browser. Nothing is sent anywhere. No account is needed, no cookies are set and no analytics run. See thePrivacy Policy. The “Copy share link” button puts your settings after the “#” in the address; browsers do not send that part to servers, and the page’s canonical address never includes it.

FAQ

Related

• RAG Text Chunker

  Split text by characters, tokens or sentences with overlap.

• Local LLM VRAM Calculator

  Weights + KV cache + overhead, and whether it fits your GPU.

• Context Window Checker

  Will your prompt, chunks and answer fit the context window?

• Guide: Vector database sizing: precision, dimensions, overhead

  Estimate RAM and disk for a vector index from vector count, dimensions and precision, what HNSW links add, and how quantisation changes size. With examples.

Sources

• Faiss wiki: Guidelines to choose an index (HNSW memory estimate, RaBitQ size) – checked 2026-10-14

Page last updated 2026-10-14. Written by Prajyot Mulik; see the editorial policy.