The vector database cost calculator above converts a vector count, an embedding dimensionality, and a precision choice into the actual size of the index you will be hosting, then prices it at a rate you control. It accounts for the two things back-of-envelope estimates always miss: the index structure that sits on top of the raw vectors, and the metadata stored beside them.
Arb Digital sizes this before recommending a vector store, because the decision between a managed service, a self-hosted cluster, and a plain database extension turns entirely on how many gigabytes you are actually going to keep in memory. The naive calculation — vectors times dimensions times four bytes — routinely understates that by half.
What This Vector Database Cost Calculator Does
Enter how many vectors you store, their dimensionality, and the numeric precision your index uses. Add index overhead, per-vector metadata, and replica count, then set a price per gigabyte per month and a price per million queries. The headline result is the total monthly cost. The grid shows total index size in gigabytes, the storage and query components separately, and a normalised cost per million vectors that makes comparing providers straightforward.
The bars split total storage into raw vectors, index structure, and metadata. That split is the useful part: if metadata dominates, the fix is to stop storing document text in the vector store. If the vectors dominate, the fix is quantisation or fewer dimensions.
How to Use It
- Enter your vector count. This is chunks, not documents. The RAG chunk size calculator converts a corpus into a chunk count if you have not indexed yet.
- Set dimensions. Your embedding model determines this. Some current models support truncating output to fewer dimensions, which reduces storage proportionally.
- Choose precision. Full float32 is the default in most systems; quantised formats trade a little recall for a large memory reduction.
- Set index overhead and metadata. Graph indexes typically add tens of percent; metadata is whatever you store per record beyond the vector itself.
- Set replicas and pricing, then click Calculate. Compare the storage and query bars before deciding what to optimise.
The Formula / How It's Calculated
Raw vector storage is vectors × dimensions × bytes per value. Five million vectors at 1,536 dimensions in float32 is 5,000,000 × 1,536 × 4, or about 30.7 GB before anything else. Index overhead multiplies that: raw × (1 + overhead%). Metadata is added as vectors × metadata bytes, and the whole total is multiplied by replica count.
Cost is then gigabytes × price per GB plus queries ÷ 1,000,000 × price per million queries. Gigabytes here are decimal, matching how cloud providers bill; if your provider quotes binary gibibytes, the figure is about 7% lower for the same bytes. Nothing in this calculation is exotic — it is only ever wrong because a component was left out.
The Index Is Bigger Than the Vectors
Approximate nearest neighbour search does not scan every vector. It navigates a structure built over them, and that structure has to be stored too. The widely used HNSW approach, introduced in the hierarchical navigable small world graph paper by Malkov and Yashunin, builds a layered graph in which every vector holds links to a fixed number of neighbours. Those links are the overhead, and they scale with the connectivity parameter rather than with dimensionality.
Raise connectivity and you get better recall, faster search, and a larger index. Lower it and the index shrinks while recall degrades, particularly on high-dimensional data. The 40% default here is a reasonable planning figure for a typical configuration, but it is a parameter you control, not a constant — if you are tuning for recall on a large corpus, measure it in your own deployment rather than trusting any published estimate.
Precision Is the Largest Lever You Are Not Pulling
Vector storage scales linearly with bytes per value, so precision is a direct multiplier on the biggest component of your bill. Moving from float32 to float16 halves it. Moving to int8 quantisation cuts it to a quarter. Binary quantisation, where each dimension becomes a single bit, reduces it by a factor of thirty-two.
The trade is recall. Quantisation introduces error into distance calculations, so the nearest neighbours returned are approximately the ones you would have got at full precision. A widely used pattern recovers most of that loss: search the quantised index to retrieve a generous candidate set quickly, then re-rank those candidates using full-precision vectors fetched from cheaper storage. You get quantised memory economics with something close to full-precision quality, at the cost of one extra step in the query path. Switch the precision selector above and watch the monthly figure move before you dismiss this as a micro-optimisation.
Dimensions Are Negotiable More Often Than People Think
Storage scales linearly with dimensionality too, so halving dimensions halves the vector portion of the index. Several current embedding models are trained so that their output can be truncated to a shorter length while retaining most of its usefulness, which makes this a configuration choice rather than a model change. OpenAI's embeddings guide documents the dimension parameter and how shortened embeddings behave.
Note what this does and does not affect. Shortening dimensions reduces storage, memory, and query latency. It does not reduce what you pay to generate the embeddings, because that is billed on input tokens — the embedding cost calculator covers that side separately. Changing dimensions also requires re-embedding the entire corpus, so it is a decision best made before the first index is built rather than after.
Metadata Quietly Becomes the Whole Bill
It is convenient to store the chunk text alongside its vector so a search returns something readable in one round trip. At the default 500 bytes per vector that is 2.5 GB across five million records, which is modest. Store the full chunk text — a 512-token chunk is roughly 2 KB — plus a document title, URL, timestamps, and permission fields, and metadata can rival the vectors themselves.
At small scale this does not matter. At tens of millions of records, in a system priced on memory, it matters a great deal. The alternative is to store only an identifier and the fields you filter on in the vector index, and keep the text in ordinary object storage or a relational database at a fraction of the price. It costs one extra lookup per query and it is often the difference between two cluster sizes. Set the metadata field to your real per-record size and watch the third bar to see whether this applies to you.
When a Dedicated Vector Database Is Not Worth It
Below roughly a million vectors, a vector extension on a database you already run will usually serve queries fast enough, and it removes an entire system from your architecture along with its cost, its operational burden, and the need to keep two stores consistent. The pgvector extension for PostgreSQL is the common example, and it supports the same approximate index types as dedicated products.
Dedicated vector databases earn their place at scale, where index build time, memory-tier management, sharding, and high query concurrency become real engineering problems. The honest test is to run this calculator at your projected size in twelve months, not today's. If the index still fits comfortably in the memory of a machine you already pay for, the simpler architecture is likely the cheaper one — and migrating later is far easier than unwinding a distributed system you did not need.
Arb Digital sizes retrieval infrastructure against real corpus growth and query volume, so you buy the architecture you need rather than the one in the tutorial.
Browse Free Tools Talk to Arb DigitalCommon Mistakes to Avoid
- Sizing from raw vectors alone — the index structure and metadata frequently add more than half again on top of the vector bytes.
- Forgetting replicas — a highly available deployment stores the whole index more than once, and the bill scales with it.
- Storing full chunk text in the vector index — text belongs in cheap storage, with only identifiers and filter fields kept beside the vectors.
- Leaving precision at float32 by default — quantisation with full-precision re-ranking preserves most recall at a fraction of the memory.
- Sizing for today's corpus — index cost is driven by growth, and rebuilding under pressure is far more expensive than planning for it.
Related Free Tools From Arb Digital
Convert a corpus into chunks with the RAG chunk size calculator, price the embeddings themselves in the embedding cost calculator, size the tokens with the AI token calculator, cost self-hosted inference in the GPU cost calculator, and check the generation side with the LLM cost comparison tool. More in the free online tools hub.
Frequently Asked Questions
Multiply the number of vectors by dimensions by bytes per value, then add index overhead for the graph structure and metadata stored per record, and multiply the total by your replica count. Raw vector bytes alone typically account for well under half the deployed size.
Proportionally to the bytes per value. Float16 halves vector storage against float32, int8 reduces it to a quarter, and binary quantisation to a thirty-second. The cost is some loss of recall, which re-ranking a candidate set at full precision can largely recover.
It can, but several current embedding models are trained so their output can be truncated with limited loss. The effect on your own corpus should be measured with a retrieval evaluation set rather than assumed either way.
Approximate nearest neighbour indexes store a navigable graph over the vectors, and every vector holds links to neighbours. Higher connectivity improves recall and search speed while increasing index size.
It is convenient at small scale and expensive at large scale, since vector stores are usually priced for memory rather than bulk storage. Keeping only identifiers and filter fields beside the vector, with text in object storage, is the cheaper pattern.
Below roughly a million vectors, an extension on a database you already operate is usually sufficient and simpler. Dedicated systems become worthwhile as index size, build time, and query concurrency grow beyond what a single ordinary instance handles comfortably.
Pricing models vary — some providers charge per query or per read unit, others bundle queries into an instance price. Enter whichever applies to your provider, and check whether metadata filtering or large candidate sets are billed differently from simple searches.
Figures produced by this tool are planning estimates only — actual size and cost depend on your index configuration, your provider's pricing model, and how much data you store per record.
