What this estimate does and does not do
This calculator estimates the cost of generating text embeddings and storing the resulting vectors in a vector database. It is designed for RAG, semantic search, recommendations, and similar AI systems.
It does not produce a guaranteed provider bill. Real costs depend on tokenizer output, current embedding prices, batch discounts, failed/retried jobs, vector database pricing, metadata design, index type, replicas, compression, query/write units, and whether the provider bills by storage, RAM, node size, or usage. Use this calculator for planning and comparison, then validate with your chosen embedding model and vector database.
Formula used
total input tokens = vector count × average tokens per vector
embedding cost = total input tokens / 1,000,000 × price per 1M tokens × discount factor
raw bytes per vector = dimensions × bytes per value
raw vector storage GB = vector count × raw bytes per vector / 1,000,000,000
stored bytes per vector = raw bytes per vector × (1 + index overhead %) + metadata bytes
replicated storage GB = vector count × stored bytes per vector × replicas / 1,000,000,000
monthly storage cost = replicated storage GB × storage price per GB-monthWorked example
For 1,000,000 chunks, 350 tokens per chunk, text-embedding-3-small-style pricing at $0.02 per 1M tokens, 1,536 dimensions, float32 storage, 500 bytes metadata per vector, and 35% index overhead:
tokens = 1,000,000 × 350 = 350,000,000
embedding cost = 350M / 1M × $0.02 = $7.00
raw bytes/vector = 1,536 × 4 = 6,144 bytes
raw vector storage = 1,000,000 × 6,144 / 1e9 = 6.14 GB
stored bytes/vector = 6,144 × 1.35 + 500 = 8,794.4 bytes
indexed storage = 8.79 GBHow to use the result
- Use the one-time embedding cost for initial indexing or backfills.
- Use monthly refresh cost for changed, new, or re-embedded content.
- Use raw storage to compare embedding dimensions and precision.
- Use indexed/replicated storage to estimate a more realistic vector database footprint.
- Pair this with the LLM Context Window and RAG Chunk Calculator to estimate vector count from chunking.
Assumptions and limitations
- Storage is shown in decimal GB because many cloud services price storage by GB-month.
- Float32 uses 4 bytes per dimension, float16 uses 2, int8 uses 1, and binary uses 1 bit per dimension.
- Index overhead is an editable approximation. HNSW, IVF, PQ, flat indexes, and provider-specific storage engines behave differently.
- Metadata can dominate storage if you store large source text, JSON blobs, ACLs, or filter fields in the vector database.
- Query costs, read/write units, minimum monthly platform fees, egress, and compute are not included in the core storage estimate.
Frequently asked questions
How do you calculate embedding generation cost?
Multiply the number of vectors by average tokens per vector, divide by one million, then multiply by the embedding model price per million tokens.
How do you calculate raw vector storage?
Raw vector storage is vector count × dimensions × bytes per value. A float32 value uses 4 bytes, so a 1,536-dimensional vector is 6,144 bytes before metadata and indexing.
Why does the calculator add index overhead?
Vector databases store more than raw vectors. HNSW graphs, metadata, IDs, deleted-document overhead, padding, and database internals can add meaningful storage and memory overhead.
Do smaller embedding dimensions reduce API cost?
Usually no. Most embedding APIs charge by input tokens, not output dimensions. Smaller dimensions mainly reduce vector database storage, memory, and sometimes query latency.
Are the pricing presets exact?
No. They are planning examples. Provider prices, batch discounts, free tiers, and vector database pricing can change, so check the current pricing page before budgeting.