Vector Database Size Calculator
Inputs
| Vector Count | 1,000,000 |
|---|---|
| Dimensions | 1,536 |
| Bytes per Value | 4 |
| Index Overhead | 25 % |
Vector Database Size Calculator
Estimate the storage footprint of an embedding index from the vector count, vector dimension, bytes per value, and the index overhead added by approximate-nearest-neighbour structures.
Inputs
Vectors
Index
Results
Enter a value to see results.
Details
Vector database size explained
Vector database size is the amount of storage needed to hold a set of embedding vectors together with the search index built over them. When a retrieval system embeds a corpus, each document chunk becomes a vector — a fixed-length list of numbers — and all of those vectors have to live somewhere that supports fast similarity search. The footprint is driven by three things: how many vectors there are, how long each vector is, and how many bytes each value occupies.
How the footprint adds up
A single vector is an array of dimensions numbers. Each number is stored at a
chosen precision: 4 bytes for a 32-bit float, 2 bytes for a 16-bit float, or 1
byte for an 8-bit quantised integer. Multiplying the byte size of one value by
the dimension gives the size of one vector, and multiplying by the number of
vectors gives the raw payload.
On top of the raw vectors sits the index. Comparing a query against every stored vector is accurate but slow once the count reaches the millions, so vector databases build an approximate-nearest-neighbour structure — most commonly an HNSW graph — that lets search visit only a small fraction of the vectors. That graph stores neighbour links for every vector, and those links are extra data, usually adding somewhere between a fifth and a half of the raw size.
The formula
With vectors of dimension , each value taking bytes, the raw storage is
Sraw=N⋅d⋅band adding a fractional index overhead gives the total:
S=Sraw⋅(1+o)Worked example
Consider a store of 2,400,000 vectors from a model with dimension 768, kept at full precision so each value takes 4 bytes, with an HNSW index that adds 35 percent overhead. The raw size is
Sraw=2,400,000×768×4=7,372,800,000 bytes≈7.37 GBand with the index,
S=7.37 GB×1.35≈9.95 GBSwitching the same vectors to 8-bit quantisation, 1 byte per value, would drop the raw size to about 1.84 GB and the total to roughly 2.49 GB — a fourfold reduction — at the cost of a small loss of precision in the distance computation.
Notes and variations
The estimate covers vectors and the index only. Most databases also store the original text chunk and metadata next to each vector; for short chunks that payload can be comparable to the vector itself, so add it separately when sizing total disk. Dimension reduction and quantisation are the two main levers for shrinking an index: halving the dimension or quantising to int8 each cut the raw size substantially before any index overhead is applied.
Application
Storage size is the input to hosting cost — once you know how many gigabytes an index occupies, the Vector Database Cost Calculator turns that into a monthly bill. The vectors being sized here are produced by the embedding step priced in the Embedding Cost Calculator, and the number of vectors usually follows from how the source documents are split.
Frequently Asked Questions (FAQ)
Why does the index add overhead?
Storing the raw vectors lets you compare a query against every vector, but that brute-force scan is slow at scale. Approximate-nearest-neighbour indexes such as HNSW build a navigable graph so search visits only a small fraction of the vectors. That graph stores neighbour links for every vector, which is extra data on top of the vectors themselves — commonly 20 to 50 percent more, depending on how densely the graph is connected.
How much does quantisation save?
Embedding values are produced as 32-bit floats, 4 bytes each. Storing them as 16-bit floats halves the footprint, and 8-bit integer quantisation cuts it to a quarter. Quantisation introduces small rounding errors in the distance computation, but for retrieval the loss in ranking quality is usually minor, so int8 is a common way to shrink a large index. The bytes-per-value field lets you compare the three options directly.
Does this include metadata and text?
No. The estimate covers the vectors and the search index only. Most vector databases also store the original text chunk and metadata such as document IDs, titles, and tags alongside each vector. That payload can rival or exceed the vector size for short chunks, so add it separately when sizing total disk usage.
Disclaimer
This is an approximate footprint for the vectors and index. Real databases also store the source text, metadata, and internal bookkeeping, and the overhead of a specific index depends on its configuration. Treat the result as a planning estimate, not an exact disk figure.