Vector database sizing: precision, dimensions, overhead

Last updated 2026-10-14 · by Prajyot Mulik

Try the tool: Vector DB Size Calculator

Before you pick a vector database or a server size, it helps to know roughly how big your index will be. The estimate is simple arithmetic on three numbers (how many vectors, how many dimensions each, and how many bytes each dimension takes) plus whatever the index structure adds. This guide walks through it with examples you can check in the Vector DB Size Calculator. It estimates the size of the data, not the exact footprint of any particular product.

The basic formula

vector bytes = number of vectors × dimensions × bytes per dimension

The dimension count is fixed by your embedding model (768, 1,024, 1,536 and 3,072 are common values; check your model’s documentation). The bytes per dimension depend on how you store the vectors:

For one million 1,536-dimension float32 vectors: 1,000,000 × 1,536 × 4 = 6,144,000,000 bytes, which is 5.72 GiB. At 768 dimensions the same vectors take 2.86 GiB; at 3,072 dimensions, 11.44 GiB. Size scales linearly with the number of vectors, so ten million 1,536-dimension float32 vectors need 57.2 GiB for the raw vectors alone.

What quantisation does to the numbers

Storing less precision per dimension shrinks the index proportionally. For ten million 1,536-dimension vectors:

Binary storage is exactly 32 times smaller than float32 when the dimension count is a multiple of 8. The saving is real, but it is not free: reduced precision can lower search accuracy (recall). The calculator measures size only; whether a smaller representation is accurate enough for your data is something to evaluate with your own queries. A common pattern is to search a compressed copy and re-score the best candidates against the original vectors kept on disk, which the calculator models as the “keep float32 originals on disk” option: it adds disk space but no RAM.

The Faiss documentation gives other examples of compressed sizes. Its RaBitQ method compresses to one bit per dimension plus a small overhead, quoted as d ÷ 8 + 8 bytes per vector, which for 1,536 dimensions is 200 bytes (about 0.19 GiB per million vectors). A product-quantised index with 4-bit codes needs M ÷ 2 bytes per vector for M sub-quantisers. These figures are index-specific; they illustrate how far compression can go, not what your database will do.

Index overhead

The vectors are not the whole index. Graph indexes such as HNSW store links between vectors so a search can hop quickly towards neighbours. The Faiss wiki gives the memory use of an HNSW index as (d × 4 + M × 2 × 4) bytes per vector, where d is the dimension and M is the number of links per vector (it suggests values from 4 to 64). The M × 2 × 4 term is the link storage: 2M links per vector at 4 bytes each. With M = 32 that is 256 bytes per vector. For one million 1,536-dimension float32 vectors the links add 256,000,000 bytes (about 244 MiB, roughly 4% on top of the 5.72 GiB of vectors). For ten million vectors with M = 32 they add 2.38 GiB.

With short vectors the links become a larger share. With binary vectors of 192 bytes, 256 bytes of links would more than double the footprint, which is one reason index choice matters when you compress aggressively. The link cost in the Faiss estimate does not shrink with vector precision.

Other systems build different structures. For those, the calculator offers a custom overhead percentage of the vector bytes, but it deliberately suggests no default: the right number depends on the database, index type and settings, and you should measure it by loading a sample.

RAM versus disk

RAM is usually the expensive resource, so it helps to separate the two:

• RAM holds the vectors you search and the index links: vector bytes + index overhead.
• Disk holds everything that must persist: the same data, plus per-vector payload (ids, text, JSON metadata) and, if you use the re-scoring pattern above, the original float32 vectors.

Payload can dwarf the vectors. 500 bytes of metadata per vector on one million vectors is 500 MB, about 8% of the 6.1 GB float32 vector data, but for small vectors it can be larger than the vectors themselves.

What the estimate leaves out

• Replicas and shards. Multiply by the number of copies you run.
• Headroom. Databases need free memory for caches, merges, write buffers and the operating system. Plan for a margin instead of loading to 100%.
• Growth. Re-embedding with a larger-dimension model, or adding documents, scales the index linearly.
• Product differences. Each database stores ids, metadata and indexes in its own way. Use this estimate to shortlist hardware, then confirm with a load test.

A quick checklist

1. Count your vectors. If they come from documents, choose a chunk size first, because smaller chunks multiply the count.
2. Look up your embedding model’s dimension.
3. Pick a storage precision you have validated for recall.
4. Choose an index and its overhead; measure it if it is not HNSW.
5. Add payload, replicas and headroom.
6. Compare RAM with the machines you can run, and keep the arithmetic in a share link so others can check it.

Sources

All pages were read on 14 October 2026. The arithmetic in the examples is covered by this site’s automated tests.

• Faiss wiki: Guidelines to choose an index – HNSW memory estimate (d × 4 + M × 2 × 4 bytes per vector), RaBitQ size (d ÷ 8 + 8 bytes), 4-bit PQ size (M ÷ 2 bytes)