The storage math you should do first
So the raw storage for vector embeddings is: items × dimensions × 4 bytes.
A single OpenAI text-embedding-3-large call produces a 3,072-dimension vector. Store a million documents with that model and you’re looking at roughly 12GB of raw vector data before any indexing overhead. At 1,024 dimensions, a million items is closer to 4GB. Ten million items at 1,024 dimensions is about 40GB.
Then add index overhead. HNSW — the graph structure from the 2016 paper that most systems use — maintains link structures between nodes, and those links consume meaningful additional memory beyond the vectors themselves. Budget well above the raw number.
Two implications people miss. Dimension choice is a cost decision, not just a quality one — a 1,536-dimension embedding costs exactly twice a 768-dimension one to store, forever. And higher-dimension isn’t reliably better; many modern models match or beat older high-dimension ones at fewer dimensions, so paying for 3,072 dimensions without testing whether 768 performs comparably on your data is a common and expensive default.
Quantization: the lever that changes everything
If the vector embeddings arithmetic above alarmed you, quantization is the answer, and it’s more effective than most teams expect.
Scalar quantization
reduces each number from 32-bit float to 8-bit integer, cutting memory roughly 4× with minimal recall loss. This is the safe default and there’s rarely a reason not to use it.
Binary quantization
goes much further — reducing each dimension to a single bit, for compression up to 32× smaller and substantially faster search. The recall hit is real but largely recoverable by re-ranking the top candidates against full-precision vectors. Weaviate, Qdrant, and Milvus all support it. The practical effect is dramatic: a Weaviate index costing roughly $135/month at 10 million vectors drops toward $30/month with binary quantization applied.
Product quantization
splits vectors into chunks and replaces each with a compact code — aggressive compression for very large indexes where RAM is the binding constraint.
Disk-backed indexes
keep most vector embeddings on SSD rather than in memory, trading some latency for a much cheaper cost curve. Milvus’s disk-based indexing is a well-known example, and it saves substantial money at billion scale.
The honest framing: quantization is a first-class architectural decision on any sizeable index, not an optimization to consider later. Decide it deliberately, measure recall before and after against brute-force ground truth, and revisit whenever your catalog doubles. Our nearest neighbor search guide covers why unmeasured recall degrades silently.
AI Search Grader by bCloud AI
Grade your ecommerce search in 10 quick questions
31% of ecommerce searches return zero results — and most shoppers who hit a dead end leave for a competitor. How does your store's search stack up?
Answer 10 short questions and get your AI search score, plus a personalized report to fix the gaps. Free, takes about 2 minutes.
No signup needed to take the quiz.
Understanding intent…
Scoring your answers across relevance, AI, experience, and insights.
Your AI search score is ready
Tell us where to send your personalized report. You'll see your score and recommendations right away.
Your score by pillar
Personalized recommendations
Fix the gaps in weeks, not quarters
bCloud AI replaces keyword-only search with hybrid AI retrieval — sub-200ms responses, 99.99% uptime, and conversion lifts of up to 40% across 50+ implementations.
Where to store vector embeddings
Four options for vector embeddings storage, and the right one depends more on scale and existing infrastructure than on features.
Postgres with pgvector.
A free extension for vector embeddings turning a database you already run into a vector store. No new service, no sync layer, no additional vendor — around $45/month on RDS at 10 million vectors, which is really just your existing instance. Since HNSW indexing arrived it performs comparably to dedicated systems at moderate scale. Below a few million vector embeddings this is the pragmatic default and plenty of teams never outgrow it.
Dedicated vector databases.
Qdrant, Weaviate, Milvus, Pinecone, and others, built specifically for this workload with better filtering, quantization options, and scaling. Worth the added system past tens of millions of vectors or when you need capabilities Postgres can’t express. Our Pinecone alternatives and vector database comparison guides cover the field.
Search engines with vector support.
Elasticsearch and OpenSearch store vector embeddings alongside a mature keyword index, which is convenient if you already run them and want hybrid retrieval — see vector database hybrid search.
Object storage for the source of truth.
Not a search index, but see the next section, because this is the piece most architectures are missing.
The cold storage pattern worth adopting now
Here’s an architectural decision that costs nothing today and saves real money later.
Keep your source-of-truth vector embeddings in object storage — S3, GCS, or Parquet files — separately from whichever system indexes them for search.
The reason is migration. Moving a hundred million vectors out of a managed vector database generates a substantial egress bill on top of the engineering time, and egress charges are precisely the mechanism that makes switching feel harder than it should. If your embeddings already live in your own object storage, re-hydrating a new index means reading from cheap storage you control rather than paying to extract data from an incumbent.
The pattern has three other benefits. It makes re-indexing routine rather than a crisis — when you change index parameters or quantization settings, you rebuild from cold storage. It provides disaster recovery independent of any vendor. And it makes A/B testing infrastructure feasible: index the same embeddings in two systems and compare on your real queries.
The cost is trivial — object storage is among the cheapest infrastructure available, and vector embeddings compress reasonably in Parquet. Teams who adopt this early describe migrations as routine; teams who don’t describe them as projects.
Re-embedding: the cost nobody budgets
One more vector embeddings expense worth planning for. When you change embedding models — because a better one launched, or your provider deprecated yours — every vector must be regenerated. That’s inference cost across your entire corpus plus a full re-index.
At a million documents this is an afternoon and a modest API bill. At a hundred million it’s a migration project with real budget implications. Three ways to reduce the pain:
Choose deliberately at the start.
Model selection is a long-term commitment, not a setting. Our embedding models guide compares the current field on accuracy, dimensions, and cost.
Keep source content accessible.
You need the original text to re-embed. If your pipeline discards it after embedding, re-embedding means reconstructing your corpus first.
Prefer providers with stable model lifecycles.
Frequent deprecations mean frequent re-embedding, and that cost belongs in your vendor evaluation.
Also budget for incremental embedding: every new or edited item needs a vector, and at high catalog velocity that inference cost accumulates continuously rather than as a one-off. Our real-time indexing guide covers keeping the index current.
Multimodal and multi-vector storage
One trend reshaping storage planning: items increasingly need more than one embedding.
A product might carry a text vector from its description, an image vector from its photos, and a behavioral vector learned from how shoppers interact with it. Multimodal models can place images and text in a shared space, which enables searching a catalog by photograph — but it also multiplies your storage requirement by the number of representations you keep.
Separate indexes per modality
keeps things simple and lets you query each independently, at the cost of storing and maintaining several indexes.
Multi-vector records
— supported natively by some systems — store several vectors per item and allow querying across them, which is more efficient but requires platform support.
Fusion into a single vector
combines representations into one, minimizing storage while losing the ability to query modalities separately.
For most ecommerce catalogs, text embeddings alone remain the right starting point, with image vectors added only where visual similarity genuinely drives discovery — fashion, furniture, and home décor being the obvious cases. Adding multimodal storage before proving it moves conversion is a common way to double your vector embeddings bill for no measurable return.
Monitoring what you’ve stored
Storage isn’t a set-and-forget decision, and three things deserve ongoing tracking.
Index size growth
against your forecast. Catalogs grow faster than teams predict, and variants inflate true item counts several-fold beyond the product count you quote internally.
Recall over time.
Approximate indexes degrade as data changes and as index parameters drift from their original tuning. Re-score a fixed benchmark set monthly against brute-force ground truth so degradation appears as a trend rather than a complaint.
Cost per million vectors.
Track this as a unit metric rather than a total, because a rising total might reflect healthy growth while a rising unit cost signals an architecture problem — usually quantization that should have been applied a while ago.
Before committing to an architecture for vector embeddings:
- Do the arithmetic at 2× your projected item count and current dimensions. If the number is uncomfortable, quantization strategy becomes a selection criterion rather than an afterthought.
- Test whether fewer dimensions work. Many models offer truncation with graceful quality loss. Halving dimensions halves storage forever.
- Decide quantization deliberately and measure recall against brute-force ground truth before and after.
- Put source-of-truth embeddings in object storage from day one.
- Keep the source content so re-embedding stays possible.
- Model total cost including inference, not just storage — embedding generation is a recurring line item at high catalog velocity.
- Check whether you need a dedicated system at all, since pgvector handles a great deal more than teams assume.
Our vector database management systems guide covers the operational side, and vector database for recommendations covers the workload that generates the heaviest write volume.
For ecommerce specifically
If these vector embeddings are powering product search, one practical note. Catalogs are unusually volatile — prices, stock, and descriptions change constantly — which means your embedding pipeline runs continuously rather than as a batch job, and variants multiply your true item count several-fold beyond the product count you quote internally.
That’s a meaningful part of why managed search platforms are popular for commerce: bCloud AI includes the embedding pipeline, storage, indexing, and retrieval as one service, so the storage math and re-embedding migrations aren’t your problem. Our top semantic search solutions for e-commerce roundup compares that category against building it yourself.
Frequently asked questions
How much storage do vector embeddings need?
Roughly items × dimensions × 4 bytes for full-precision vectors, plus index overhead. A million documents at 3,072 dimensions is about 12GB of raw vector data before indexing; ten million at 1,024 dimensions is around 40GB. HNSW link structures add meaningfully on top.
What’s the best database for storing vector embeddings?
Below a few million vectors with Postgres already in your stack, pgvector is usually the right answer — no new system and no license cost. Past tens of millions, dedicated systems like Qdrant, Weaviate, or Milvus offer better filtering, quantization, and scaling. Elasticsearch works well if you need hybrid retrieval and already run it.
How do I reduce vector embeddings storage costs?
Quantization is the biggest lever: scalar quantization cuts memory roughly 4× with minimal recall loss, and binary quantization up to 32× with a recall hit recoverable through re-ranking. Also test whether fewer dimensions perform comparably, since halving dimensions halves storage permanently.
Should I store embeddings in object storage?
Yes, as a source of truth alongside whatever indexes them. Keeping embeddings in S3, GCS, or Parquet makes re-indexing routine, provides vendor-independent disaster recovery, and avoids the egress charges that make migrating away from a managed vector database expensive.
What happens when I change embedding models?
Every vector must be regenerated, which means inference cost across your entire corpus plus a full re-index. At small scale that’s an afternoon; at a hundred million items it’s a budgeted migration. Keep your source content accessible so re-embedding remains possible.
Do more dimensions mean better results?
Not reliably. Higher-dimension vectors can capture more nuance but cost proportionally more to store and search, and many modern models match or beat older high-dimension ones at fewer dimensions. Test truncated dimensions on your own data before paying for the largest option.
Skip the storage math entirely.
bCloud AI manages embedding generation, storage, indexing, and retrieval as one service — no quantization strategy to own.
bcloud.ai
