Vibe Engines is free, interactive AI engineering & system design — runs in your browser. Pick a learning path
Embedding Dimension Tradeoff
An embedding storage calculator. Enter how many vectors you have and compare the memory footprint across common embedding dimensions and quantization levels (float32, float16, int8) — so you can weigh retrieval quality against the RAM and cost of your vector index, and see what dimension reduction or quantization buys you.
| Dimensions | float32 (4B) | float16 (2B) | int8 (1B) |
|---|---|---|---|
| 256 | 14.3 GB | 7.2 GB | 3.6 GB |
| 384 | 21.5 GB | 10.7 GB | 5.4 GB |
| 512 | 28.6 GB | 14.3 GB | 7.2 GB |
| 768 | 42.9 GB | 21.5 GB | 10.7 GB |
| 1024 | 57.2 GB | 28.6 GB | 14.3 GB |
| 1536 | 85.8 GB | 42.9 GB | 21.5 GB |
| 3072 | 172 GB | 85.8 GB | 42.9 GB |
Memory ≈ vectors × dimensions × bytes/component × (1 + overhead). Dropping precision (int8 = ¼ of float32) or dimensions cuts memory linearly, usually for only a small recall loss — often recovered by re-ranking the top hits with full-precision vectors.
A vector index’s size is set by three numbers, and the text you embedded is not one of them. Memory scales with how many vectors you store, how many dimensions each has and how many bytes each component takes. This tool lays out every combination of seven common dimensions and three precisions for your vector count, so the tradeoff is a number instead of a guess.
What it computes
memory = vectors × dimensions × bytes per component × (1 + overhead / 100)- Vectors is the number of embeddings stored, usually one per chunk of text.
- Dimensions are the rows of the table: 256, 384, 512, 768, 1,024, 1,536 and 3,072.
- Bytes per component are the columns: 4 for float32, 2 for float16 and 1 for int8.
- Overhead is a percentage added on top for the index structure, such as an HNSW graph, plus IDs and bookkeeping. It defaults to 50%.
Results are printed in 1,024-based units labeled KB, MB, GB and TB, with one decimal under 100 and whole numbers above.
A worked example
With the defaults, 10 million vectors and 50% overhead, take the 1,536-dimension float32 cell:
- Raw vectors:
10,000,000 × 1,536 × 4 = 61,440,000,000 bytes. - With overhead:
61.44 billion × 1.5 = 92,160,000,000 bytes. - In 1,024-based units:
92,160,000,000 / 1,024³ = 85.8, shown as 85.8 GB.
| Dimensions | float32 | float16 | int8 |
|---|---|---|---|
| 256 | 14.3 GB | 7.2 GB | 3.6 GB |
| 768 | 42.9 GB | 21.5 GB | 10.7 GB |
| 1,024 | 57.2 GB | 28.6 GB | 14.3 GB |
| 1,536 | 85.8 GB | 42.9 GB | 21.5 GB |
| 3,072 | 172 GB | 85.8 GB | 42.9 GB |
The grid is linear in both directions. Halving the dimensions or halving the bytes each halve the memory, so 3,072 at float16 equals 1,536 at float32, and moving from 1,536 float32 to 768 int8 is an eightfold saving, 85.8 GB down to 10.7 GB.
Assumptions and limits
- A flat overhead percentage. Graph indexes mostly add a fixed number of bytes per vector for neighbor links, not a fixed share. That share is small next to a 6 KB float32 vector and large next to a 256-byte int8 one, so the same 50% overstates big vectors and understates small ones. Measure your index if the number matters.
- Vectors only. Metadata, document text, filters, replicas and the database process are not counted.
- No quality estimate. The tool shows cost, not recall. Whether 768 dimensions or int8 storage is good enough depends on your model and queries.
- Dimensions are the model’s choice. You cannot pick 512 from a 1,536-dimension model unless it supports truncation, such as models trained with Matryoshka Representation Learning.
- No binary or product quantization. One-bit and compressed codes go well below int8 and are not in the grid.
How to use the result
- Find the cell that fits your memory budget, then test retrieval quality at that dimension and precision on a sample of real queries before committing.
- Try quantization first. int8 storage often keeps recall close to float32, and re-ranking the top results with full-precision vectors recovers much of what it loses. Truncation only works with models trained for it.
- Budget for growth. Memory scales with vector count, so a corpus that doubles doubles every cell; size from next year’s count.
- Remember the multipliers. Each replica holds a full copy, and in-memory indexes need headroom to rebuild.
How it works
- Memory ≈ vectors × dimensions × bytes/component × (1 + overhead).
- Compares float32 (4 B), float16 (2 B) and int8 (1 B) side by side.
- Seven common dimensions from 256 to 3,072, sized in 1,024-based units.
- Higher dimensions cost linearly in RAM, compute and index size.
Frequently asked questions
How much memory does a vector index take?
Roughly the number of vectors times the dimensions times the bytes per component, plus index overhead. A float32 component is 4 bytes, so 10 million 1,536-dimension vectors is 61.4 billion bytes of raw vectors, about 57 GB in the 1,024-based units this tool uses, before the graph or list structure an approximate nearest neighbor index adds. That is why dimension and vector count, not the size of the original text, dominate a vector database’s memory.
How much RAM do I need for one million embeddings?
With this tool’s default 50% index overhead, one million float32 vectors need about 8.6 GB at 1,536 dimensions, 4.3 GB at 768 and 2.1 GB at 384, counting a gigabyte as 1,024 cubed bytes. Storing them as int8 cuts each figure to a quarter. Add memory for metadata, the database process itself and headroom for growth, and remember replicas multiply the total, so production nodes are usually sized well above the raw estimate.
What does quantization trade away?
Storing each component in fewer bytes shrinks the index proportionally: float16 halves it compared with float32, and int8 cuts it to a quarter. The cost is a small loss of precision, which usually causes only a minor drop in retrieval recall, often well worth a fourfold memory saving. A common pattern is to search over int8 or binary vectors first and then re-rank the top candidates with full-precision vectors to recover most of the lost accuracy.
Are more dimensions always better for quality?
No. Higher dimensions can capture more nuance, but with diminishing returns, and they cost linearly more memory, more compute per similarity comparison and a larger index. Past a point, extra dimensions add cost without meaningfully improving retrieval on your data. The right dimension is the smallest one that clears your quality bar on your own queries, measured with a recall or ranking metric, not the largest the model offers.
What is Matryoshka (MRL) truncation?
Some embedding models are trained with Matryoshka Representation Learning, which packs the most important information into the leading dimensions. That lets you keep only the first 512 or 256 numbers of a longer vector and retain most of the retrieval quality, shrinking memory and speeding search without re-embedding your documents. Truncated vectors should be re-normalized before cosine search, and the trick only works with models trained this way.