One million documents embedded at 3,072 dimensions produce roughly 12 gigabytes of raw vector data before indexing overhead. Add the standard HNSW index and that number grows by another 50 percent. Most teams estimate their vector database storage once, at the start, and never revisit the math again.
One million documents embedded at 3,072 dimensions, the size OpenAI's text-embedding-3-large model produces, generate roughly 12 gigabytes of raw vector data before any indexing overhead is added. Apply a standard HNSW index, the most common vector search structure, and storage grows by another 50 percent on top of that. Production RAG and agent memory systems routinely end up storing 10 to 50 times more vector data than teams initially estimated, once metadata, multiple embedding models, and versioning are accounted for.
Vector databases have quietly become one of the largest line items in AI infrastructure budgets, and the gap between what a pricing page implies and what a production bill actually looks like averages 2.5 to 4 times higher, according to infrastructure cost analysis published this year. This guide covers the real storage math, what the major options actually cost at scale, and how to architect around the surprises.
Vector storage cost is driven by three multiplying factors, and most initial estimates only account for the first one.
Higher-dimension embeddings cost proportionally more to store and query. A 1,536-dimension embedding, OpenAI's text-embedding-3-small, costs roughly half of what a 3,072-dimension embedding from the larger model costs at the same volume. Dimension count is usually the first lever worth checking before scaling storage: many production RAG workloads get equivalent retrieval quality from the smaller, cheaper embedding size.
HNSW, the graph-based index most vector databases use by default, adds roughly 1.5x storage overhead on top of the raw vector data to build the navigable graph structure that makes fast approximate search possible. This overhead is not optional if you want fast search, but it needs to be budgeted for from the start rather than discovered later.
Metadata fields, multiple embedding model versions kept in parallel during a migration, and re-indexing after a model upgrade all compound on top of the base storage estimate. The 10x to 50x gap between initial estimate and actual production storage cited in current cost analyses comes almost entirely from this category, not from underestimating the base embedding size.
The cost curve between managed and self-hosted vector databases is not linear, it bends sharply at scale. At modest volume the difference is minor. Past roughly 50 to 100 million vectors, the gap becomes the entire decision.
| Database | At 10M Vectors | At 100M Vectors |
|---|---|---|
| Pinecone (Serverless) | ~$70/month | $700+/month |
| Weaviate Cloud | ~$135/month | Needs careful capacity planning |
| Qdrant Cloud | ~$65/month | Stays under $100/month self-hosted |
| pgvector (on RDS) | ~$45/month | Stays under $100/month self-hosted |
At 10 million vectors, the spread across major providers is modest, roughly $45 to $135 a month. At 100 million vectors, that spread explodes: Pinecone's serverless pricing can reach $700 or more a month, while self-hosted Milvus or pgvector deployments commonly stay under $100 a month at the same volume, provided the operational capacity exists to run them. The trade-off is explicit: managed services convert an operations problem into a bigger bill; self-hosting converts a bigger bill into an operations problem. Neither is free, and the right answer depends entirely on whether your team has infrastructure capacity to spend instead of budget.
Three specific line items account for most of the gap between a pricing page estimate and the actual monthly bill.
Moving vector data between providers, from a hyperscaler-hosted database to a different vendor, for example, triggers standard cloud egress charges, typically $0.08 to $0.09 per gigabyte on AWS. Moving 100 million vectors between providers can generate a genuinely large one-time egress bill that rarely appears in anyone's initial cost model.
Rebuilding an HNSW index after a bulk update or a model migration costs roughly $12 to $40 in compute per 10 million vectors, a cost that recurs every time the underlying embedding model changes or a large batch of new data is ingested.
Systems with high-frequency delete-and-replace patterns, common in real-time agent memory, generate ongoing write-unit costs on usage-based pricing models that are easy to underestimate if the initial cost model only accounts for steady-state storage and query volume, not the churn rate.
Scale should drive the default choice more than brand familiarity or marketing. Here's how the decision typically breaks down:
| Scale | Recommended Default | Why |
|---|---|---|
| Under 1M vectors | pgvector in existing Postgres | No new system, SQL joins with source data, lowest operational cost |
| 1M to 50M vectors | Qdrant, managed or self-hosted | Best cost-to-performance ratio, strong filtering, no per-query fee |
| 50M to 100M vectors | Weaviate (with capacity planning) or Qdrant | Still viable, but memory and compute use need active monitoring |
| 100M+ vectors | Milvus or Zilliz Cloud | Disk-based indexing built for this scale, avoids all-RAM cost blowup |
For most RAG workloads under a few million vectors, pgvector inside an existing PostgreSQL database is the strongest starting point, since it avoids standing up a new system entirely and keeps embeddings queryable alongside the source documents and metadata with ordinary SQL joins. Benchmark data shows pgvectorscale reaching 471 queries per second at 99 percent recall on 50 million vectors, which is fast enough for the large majority of production RAG and agent applications well before a dedicated vector database becomes necessary. This ties directly into why storage functions as the anchor of the AI infrastructure stack rather than an afterthought.
The single most effective architectural decision for avoiding the worst vector database cost surprises has nothing to do with which vector database you pick: store your source-of-truth embeddings in object storage first, then index them into whichever vector database you're using at the time.
Keeping the canonical copy of your embeddings in S3-compatible object storage, ideally a zero-egress provider like Backblaze B2 or Wasabi, means switching vector database vendors later, or re-indexing after a model upgrade, never requires paying an egress fee to extract your own data from a vendor that no longer fits. You re-hydrate a new vector index directly from your own object storage instead. This is the same architectural principle behind building against a portable API standard rather than a single vendor: the vendor underneath becomes replaceable rather than load-bearing.
The vector database is not where your embeddings should live permanently, it's where they get searched. Keep the source of truth somewhere you control, and the database underneath becomes a choice instead of a trap.
Compare AWS, Google Cloud, Azure, and alternatives like Backblaze B2 Discover how much you could save in seconds
