TokenPad
RAG

Vector Database Storage Estimator

How much disk your embeddings need, and what quantisation would save.

Settings
Vector StorageExact
0Token change
Token change0no change
Input tokens0what you pasted
Output tokens0what you would send
Token cost of this result
Output tokens0
As input$0.00
× 100K requests$0.00

Everything on this page runs in your browser. Nothing you paste is transmitted, because there is no server here to transmit it to.

Result
 

Where the bytes go

A vector is dimensions times bytes per value. At 1,536 dimensions in float32 that is six kilobytes per chunk before anything else — half a million chunks is three gigabytes of raw vectors.

Then metadata, then the chunk text if you store it alongside, then roughly thirty percent on top for the index structure itself. The last one surprises people most.

Precision is the biggest lever

Moving from float32 to float16 halves storage. Moving to int8 quarters it. Both usually cost a small amount of recall, and how much depends entirely on your data.

The honest advice is to measure rather than assume. Build a small evaluation set, run it at each precision, and decide with numbers — the degradation is often smaller than people fear and occasionally larger.

Frequently asked questions

Should I store the chunk text in the vector database?
It is convenient and it is not free. If you already have the text in a primary store keyed by chunk id, fetching it from there keeps the vector store lean and the search fast.
Are more dimensions better?
Not automatically. Many current models support reducing dimensions at negligible accuracy cost, and the smaller vector is cheaper to store and faster to search. Test the reduced version before defaulting to the largest.

More rag tools