Vector Database Pricing Compared for RAG Apps

Most RAG cost estimates focus entirely on LLM inference and skip the vector database almost entirely — until it shows up as a surprise line item once the corpus grows past a free tier. Vector DB cost is driven by different variables than LLM cost: storage bytes, query volume, and index configuration, not tokens. Here's how to actually size it.

What Drives Vector DB Cost

• Vector count. Not document count — chunk count. A 500K-document corpus split into 4-chunk averages is 2 million vectors, and that's the number that matters for storage and index size.
• Embedding dimensionality. Higher-dimensional embeddings (768, 1536, 3072 are all common) capture more nuance but cost proportionally more to store and index.
• Metadata payload. Source URLs, timestamps, permissions, and any filterable fields stored alongside each vector — often underestimated, and can add a meaningful fraction on top of raw vector storage.
• Query volume and pattern. Managed providers typically price on some combination of storage plus read/write operations, so a high-QPS application can end up query-cost-dominated even with a modest corpus.
• Index type and replication. An HNSW index trades memory for query speed; running multiple replicas for availability multiplies storage cost by the replica count.

Worked Example: Sizing Raw Storage

500,000 source documents, chunked to an average of 4 chunks each, embedded at 1,536 dimensions — a commonly used embedding size:

• Total vectors: 2,000,000
• Raw storage at float32 (4 bytes/dimension): 12.29 GB, or roughly 15.36 GB once you add a typical 25% for metadata payload
• Same corpus with int8 quantization (1 byte/dimension): 3.07 GB — about a 4x reduction
• Same corpus with binary quantization (1 bit/dimension): 0.38 GB — about a 32x reduction, at some cost to retrieval recall that's worth validating against your own eval set before adopting

This is the number to take to a provider's pricing calculator — most managed vector databases price storage per GB per month, so knowing your real byte footprint (not vector count alone) is the difference between an estimate and a guess.

Provider-by-Provider Comparison

Typical, approximate published rate cards at the time of writing put a mid-size corpus (low hundreds of thousands of vectors, moderate query volume) in the range of roughly $0-70/month across these providers depending on tier and whether you're still within a free tier — treat this as a rough planning band, not a quote, and check current pricing pages directly before budgeting.

The Other Half: Embedding Cost

Embedding the corpus in the first place is usually a small, often one-time or infrequent cost relative to ongoing storage and query cost — embedding models are typically priced per token at rates well below chat completion models, on the order of a few cents to a few tens of cents per million tokens embedded, though this varies by provider and model, so check current rates before budgeting. For a corpus of any real size, re-embedding strategy matters more than the raw embedding price: incrementally embedding only new or changed documents, rather than re-embedding the entire corpus on every content update, is usually the larger lever than which embedding model you pick.

Reducing Vector DB Costs

1. 1. Quantize. Int8 or binary quantization can cut storage by 4-32x, as shown above, usually with a measurable but often acceptable recall tradeoff — validate against your own retrieval eval before committing.
2. 2. Chunk deliberately, not by default. Smaller chunks mean more vectors for the same corpus. Right-size chunk length to your retrieval task instead of defaulting to whatever a tutorial used.
3. 3. Prune stale vectors. Deleted or superseded content that never gets removed from the index is pure waste — storage cost with zero retrieval value.
4. 4. Use hybrid retrieval to shrink what you need in the vector index. Combining keyword search with vector search can let a smaller, more selective vector index do less work overall.
5. 5. Match provider pricing model to your traffic shape. Pay-per-operation pricing (Pinecone-style) tends to suit spiky or low-baseline traffic; fixed-tier cluster pricing (Weaviate-style) tends to suit steady, predictable high-volume traffic — matching the wrong shape to the wrong pricing model is a common source of overspend either way.

How Query Volume Changes the Calculus

Storage cost scales with corpus size and is relatively easy to forecast — it barely changes between a quiet day and a busy one. Query cost is the volatile half of the bill. A RAG chatbot that retrieves on every conversational turn can easily generate more billable vector DB operations per month than it has documents in its corpus, especially once you factor in that a single user question often triggers more than one retrieval call (an initial broad search plus a reranking or filtered follow-up query, for instance).

As a rough, approximate planning heuristic: if your expected monthly query count is comfortably below your vector count, pay-per-operation pricing is usually cheaper. If query volume is going to run well above vector count — a busy chatbot querying the same modestly sized knowledge base thousands of times a day — a fixed-capacity tier or dedicated cluster often becomes the better deal once you cross that point, because per-operation pricing starts compounding faster than a flat monthly cluster fee. The exact crossover is provider-specific, but the direction of the tradeoff holds broadly across the pricing models above.

Common Mistakes

1. 1. Sizing by document count instead of chunk count. The gap between the two is often 3-10x, and it's the chunk count that determines storage and index cost.
2. 2. Ignoring metadata payload size. Rich metadata on every vector — full source text, multiple filterable fields — can add a large fraction on top of the raw vector bytes.
3. 3. Re-embedding the whole corpus on every update. Both an LLM cost and a vector DB write-cost problem — incremental upserts are almost always the right default.
4. 4. Provisioning a dedicated cluster before validating query volume. Serverless or pay-per-operation pricing is usually cheaper until you have a proven, steady query volume that justifies a fixed-capacity cluster.
5. 5. Adopting aggressive quantization without testing retrieval quality. The storage savings are real, but so is the recall tradeoff on some workloads — test before you standardize on it.

FAQ

Is a self-hosted vector database actually cheaper?

Only if you already have the infrastructure and ops capacity to run and monitor it. The provider fee on a managed service is partly paying for someone else to handle availability, backups, and scaling — factor in your own engineering time before calling self-hosting cheaper.

How much does quantization actually hurt retrieval quality?

It varies by embedding model and dataset. Int8 quantization is often close to lossless for retrieval ranking purposes; binary quantization is more aggressive and benefits from testing on your own eval set before adopting it in production, ideally with a reranking step to recover any lost precision on the top results.

Do I need a dedicated vector database, or is pgvector enough?

If you're already running Postgres and your vector count is in the low millions with moderate query volume, pgvector is usually sufficient and avoids adding a new system to operate. Very large corpora or high-QPS, latency-sensitive retrieval are where purpose-built vector databases tend to pull ahead.

How does this interact with agent or chatbot cost?

Retrieved chunks become part of the LLM's input on every call that uses them — see our chatbot cost estimation guide and agent cost breakdown for how retrieved context adds to the token budget on the LLM side, on top of whatever the vector database itself costs to query.

Run your own corpus size and query volume through the Vector DB Calculator for a side-by-side estimate.