Why does dimension affect storage cost?

Each vector is stored as dimension × bytes-per-float. A 3072-dimension vector at 4 bytes/float is about 12 KB; a 256-dimension vector is about 1 KB. Across millions of vectors that difference dominates your vector database bill.

Does a higher dimension cost more to embed?

The embedding API is priced per input token, not per output dimension, so embedding cost is the same regardless of dimension for a given model. Dimension mainly changes storage and, slightly, query compute — not the API call price.

Should I always use the largest dimension?

No. Many models support dimension truncation (Matryoshka embeddings) where a 256 or 512 dimension retains most retrieval quality at a fraction of the storage. Test recall on your data — smaller is often good enough and far cheaper at scale.

Is the storage estimate exact?

It is an approximation. Real vector databases add index overhead (HNSW graphs, metadata, replication) that can multiply raw vector size by 1.5-3x. Treat the storage figure as a floor and confirm with your provider.

Embedding Model Dimension vs Cost Calculator

Embedding dimension is a cost and storage decision

Bigger embeddings can mean better retrieval — but every extra dimension is bytes you store and pay for, forever, across your entire corpus. This calculator separates the one-time embedding API cost (driven by tokens) from the ongoing storage cost (driven by dimension × document count) so you can choose the dimension that balances quality and bill.

How the numbers are built

embed_cost   = (docs × tokens_per_doc)/1e6 × embed_price   (one-time)
bytes_per_vec = dimension × 4                               (float32)
storage_gb    = docs × bytes_per_vec / 1e9
storage_cost  = storage_gb × price_per_gb                   (monthly)

The embedding API charges per input token, so the dimension does not change the API price for a given model — it changes how much each resulting vector costs to store and search. At millions of documents, storage and index overhead dwarf the one-time embedding spend.

Tips for choosing a dimension

If your model supports dimension truncation (Matryoshka-style), start small (256 or 512) and only go larger if recall on your own queries demands it. Remember real vector databases add index overhead of 1.5-3x raw vector size, so the storage figure here is a conservative floor — confirm against your provider’s quote before committing at scale.