Embedding Dimension Calculator

The embedding dimension calculator turns three simple inputs — your embedding model, the number of documents, and the average number of chunks per document — into the two numbers that actually drive a vector search budget: total storage and embedding cost. An embedding is a fixed-length list of floating-point numbers (a vector) that represents the meaning of a piece of text. The length of that list is the dimension. OpenAI's text-embedding-3-large produces 3072-dimensional vectors, text-embedding-3-small and ada-002 produce 1536, Cohere Embed v3 produces 1024, and open-source Sentence Transformers commonly produce 768.

Dimension matters because every vector you store occupies dimension × 4 bytes when stored as standard 32-bit floats (float32). A 3072-dimensional vector is exactly 12,288 bytes, while a 768-dimensional vector is only 3,072 bytes — a 4× difference for the same chunk of text. When you are indexing millions of chunks in a vector database such as Pinecone, Weaviate, Qdrant, or pgvector, that multiplier decides whether your index fits in memory on a single node or needs sharding.

This calculator first multiplies documents by chunks to get the total number of vectors, then applies the float32 storage rule to estimate raw index size in megabytes and gigabytes. It separately estimates the one-time embedding generation cost by assuming roughly 250 tokens per chunk and billing those tokens at the selected model's price per 1,000 tokens. The result is a fast, model-aware sizing estimate you can use before committing to a retrieval-augmented generation (RAG) architecture.

The storage math is deterministic and easy to audit. First the tool computes how many vectors you will create:

• Total vectors = number of documents × average chunks per document.
• Bytes per vector = dimension × 4, because each coordinate is a 32-bit (4-byte) float.
• Total bytes = total vectors × bytes per vector.

The raw byte total is then converted to human-friendly units using binary (mebibyte/gibibyte) division, which is what most database dashboards report. Megabytes use a divisor of 1,048,576 (1024 × 1024) and gigabytes divide the megabyte figure by another 1024. This is the same arithmetic the calculator runs in its useMemo block, so the numbers it shows on screen are reproducible by hand.

One important caveat: this estimate covers the raw vector payload only. Production vector databases add index overhead. Approximate-nearest-neighbor (ANN) structures such as HNSW graphs store extra graph edges that can add 20% to 100% on top of the raw vectors, and you may also store the original text, metadata, and document IDs alongside each vector. Treat the calculator's gigabyte figure as a floor, then apply a multiplier appropriate to your index type. If you switch to quantized storage — for example int8 or binary embeddings — the per-vector footprint drops dramatically, which is exactly why quantization is the first lever teams pull when an index gets too large.

The embedding cost is a one-time charge for generating vectors, separate from ongoing storage. The calculator assumes an average of 250 tokens per chunk — a reasonable mid-range for the 256 to 512 token chunks common in RAG pipelines — and prices the resulting token volume at the selected model's published rate per 1,000 tokens.

• Total tokens = total vectors × 250 tokens per chunk.
• Embedding cost = (total tokens ÷ 1000) × price per 1K tokens.

The built-in price table reflects representative API rates: $0.00013 per 1K tokens for text-embedding-3-large, $0.00002 for text-embedding-3-small, $0.0001 for ada-002, $0.00012 for Voyage models, and $0.0001 for Cohere Embed v3. Open-source Sentence Transformers are priced at $0 because you run them on your own hardware — the trade-off there is compute and engineering time rather than per-token API fees.

Because the cost scales linearly with token volume, the two biggest levers are chunk count and chunk size. Splitting documents into more, smaller chunks improves retrieval granularity but raises both storage and embedding cost. Note that this is a generation estimate only; it does not include the cost of query-time embeddings, which you incur every time a user searches, nor the recurring monthly bill from your vector database host. Use the figure to compare models on a like-for-like corpus rather than as a final invoice.

Picking a model is a balance of retrieval quality, vector size, and price. Larger dimensions can capture more semantic nuance, but they cost more to store and search and are not always worth it for short, domain-specific text. The table below summarizes the models this calculator supports.

Notice that text-embedding-3-large stores four times as many bytes per vector as a 768-dimensional open-source model. For a million-vector index that is the difference between roughly 11.7 GB and 2.9 GB of raw vectors. OpenAI's v3 models also support Matryoshka dimension truncation, letting you shorten 3072-dimensional vectors to 256, 512, or 1024 dimensions with only a small accuracy loss — a practical way to claw back storage. Voyage models (1536d) are tuned for retrieval and code, while Cohere Embed v3's 1024 dimensions hit a popular middle ground for general-purpose semantic search.

To get an estimate, choose your embedding model from the dropdown, enter the number of documents in your corpus, and set the average chunks per document after your text splitter runs. If you use a model not in the list, select Custom Dimension and type the vector length your model returns; custom models are priced at $0 since the tool cannot know a private model's API rate.

The results panel surfaces five numbers. The large headline figure is the vector dimension with its provider. Total Vectors confirms the documents-times-chunks multiplication. Embedding Cost is the one-time generation estimate. The storage block then lists bytes per vector, total MB, and total GB so you can plan node sizing.

A few practical reading tips. If your gigabyte figure approaches the RAM of your intended database node, plan for quantization or sharding before launch, because ANN indexes generally want vectors resident in memory for low-latency search. If the embedding cost looks surprisingly high, revisit your chunking — fewer, larger chunks lower token volume but can hurt retrieval precision. And remember the 250-tokens-per-chunk assumption: if your chunks are routinely 500 tokens, double the displayed cost, and if they are 128 tokens, roughly halve it. The calculator is built for fast comparison and budgeting, so re-run it whenever you change models or chunking strategy to see the storage and cost impact instantly.