How much storage do my embeddings need?
Embedding a corpus turns documents into vectors, and vectors into gigabytes. The count that matters is chunks, not documents — and it is usually much larger than expected.
The short answer
Computed from this tool’s default settings — documents and the rest as most people start. Change them below for your own case.
39,063 chunks at 768 dimensions come to about 0.16 GB with index overhead. If that is uncomfortable, quantising the vectors to int8 cuts it to roughly 0.04 GB for a small recall cost.
Embedding Storage Calculator
Disk and memory for a vector index, from document count and dimension.
39,063 chunks at 768 dimensions come to about 0.16 GB with index overhead. If that is uncomfortable, quantising the vectors to int8 cuts it to roughly 0.04 GB for a small recall cost.
| Precision | Raw | With index | Trade-off |
|---|---|---|---|
| float32 | 0.12 GB | 0.16 GB | Baseline |
| float16 | 0.06 GB | 0.08 GB | Half, negligible loss |
| int8 | 0.03 GB | 0.04 GB | Quarter, small loss |
What each setting changes
Every input moves the result for a reason. This is what each one does and where to find the value for your own machine.
| Setting | Default | What it changes |
|---|---|---|
| Documents | 10000 | Your own figure, starting from 10,000. Change it to match what you actually run. |
| Average document length | 2000 tokens | Your own figure in tokens, starting from 2,000. Change it to match what you actually run. |
| Chunk size | 512 tokens | Anywhere from 64 to 2,048 tokens. |
| Embedding dimension | 768 — base class | 5 options, from 384 — MiniLM class to 3072 — OpenAI large. |
| Bytes per value | float32 — 4 bytes | Quantising vectors to int8 cuts the index by four with little recall loss. |
Real answers across embedding dimension
The same calculation run at a range of settings, with everything else left at its default. These are computed by the tool itself, not written by hand.
| Embedding dimension | Index size | Chunks embedded | Raw vectors | Per chunk |
|---|---|---|---|---|
| 384 — MiniLM class | 0.08 GB | 39,063 | 0.06 GB | 1,536 bytes |
| 768 — base class | 0.16 GB | 39,063 | 0.12 GB | 3,072 bytes |
| 1024 — large class | 0.21 GB | 39,063 | 0.16 GB | 4,096 bytes |
| 1536 — OpenAI small | 0.32 GB | 39,063 | 0.24 GB | 6,144 bytes |
| 3072 — OpenAI large | 0.64 GB | 39,063 | 0.48 GB | 12,288 bytes |
39,063 chunks at 384 dimensions come to about 0.08 GB with index overhead. If that is uncomfortable, quantising the vectors to int8 cuts it to roughly 0.02 GB for a small recall cost.
How this is calculated
No lookup tables and no invented constants. Here is the arithmetic, so you can check it against your own numbers.
A vector is dimension × bytes-per-value. Total storage is that times the number of chunks, which is documents × average length ÷ chunk size — chunks, not documents, is what gets embedded.
Indexes carry overhead on top of the raw vectors: an HNSW graph typically adds somewhere between a quarter and half again for its links. The figure below adds a third as a working estimate.
These are well-founded engineering estimates, not benchmark results. Your quantisation, runtime and context length all move the real number, and usable memory is an assumption rather than a specification. See the full methodology for every assumption behind these figures.
Who this is for
The three situations that bring people to this calculation.
Planning an index
Size storage before embedding a corpus.
Choosing a model
See what a larger dimension costs.
Cutting cost
Compare float32, float16 and int8.
How to use this calculator
Four steps, no account, nothing leaves your browser.
Set documents
Start at the top of the panel. Every figure recalculates as you change it — there is no submit button, because watching the number move is the point.
Adjust the rest to match your setup
4 further settings: average document length, chunk size, embedding dimension, bytes per value. Defaults are the common case, so change only what differs for you.
Read the headline, then the table
The large figure answers the question. The table underneath shows how the answer changes across nearby settings, which is usually where the decision actually gets made.
Check it against the method
The arithmetic is written out above. If a number looks wrong for your hardware, the assumptions are the first place to look — usable memory and quantisation are the two that vary most.
How much storage do my embeddings need: common questions
The questions people ask about this, answered without hedging.
How much storage do embeddings need?
Dimension times bytes per value, per chunk. A 768-dimension float32 vector is about 3 KB, so a million chunks is roughly 3 GB before index overhead.
Should I quantise my vectors?
Usually yes at scale. Int8 quantisation cuts storage by four with small recall loss, and most vector databases support it directly.
Does a higher embedding dimension retrieve better?
Somewhat, with diminishing returns and linear cost in storage and search time. A good 768-dimension model often beats a mediocre 3072-dimension one.
Why is my index bigger than the vectors?
HNSW-style indexes store graph links alongside the vectors, typically adding a quarter to half again. Stored metadata and source text add more.
Related local AI tools
All 50 run on the same arithmetic, so answers across them agree.
More on context
Will it fit
Speed
Quantisation
Runtime & errors
Cost
Fine-tuning
Searches this page answers
Different ways of asking the same question, all resolved above.
Now find the models that fit
Sizing is only half the problem. Model Radar takes your hardware and shows which models actually run on it, ranked by what they are good at — the same arithmetic as this page, applied to every model worth running.