Why storing vectors in S3 is 10x cheaper than traditional vector databases

The vector database market has a pricing problem. Not the vendor’s pricing — their pricing is totally rational given their architecture. The problem is that the architecture itself is expensive by design, and most teams have accepted “expensive” as the natural cost of vector search.

It doesn’t have to be.

This post walks through the actual cost math: what you pay for a 100M-vector workload on Pinecone, Weaviate Cloud, and Qdrant Cloud versus what you pay when vectors live in S3 with a query layer on top. The numbers are public. The math is simple. The difference is around 10x.

Where the cost comes from

Every major vector database in production today makes the same architectural choice: vectors live in RAM. The query-time algorithm (HNSW, IVF, FLAT — doesn’t matter) requires random access into the vector index. Random access into spinning disk is too slow. SSDs are better but not enough for sub-10ms at scale. So the index lives in RAM.

RAM is expensive. Cloud RAM in 2026 costs roughly:

• AWS r7g.16xlarge: ~$4.80/hr, 512GB RAM → $0.0094/GB/hr → $6.72/GB/month
• AWS m7g.16xlarge: ~$2.45/hr, 256GB RAM → $0.0096/GB/hr → $6.88/GB/month

Object storage costs:

• AWS S3 Standard: $0.023/GB/month
• Cloudflare R2: $0.015/GB/month
• Backblaze B2: $0.006/GB/month

That’s a 300x difference in raw storage cost between RAM and S3.

Vector databases don’t charge you raw RAM prices — they amortize hardware, operations, and replication. But they can’t escape the underlying cost structure. Their margins have to come from somewhere.

The 100M vector benchmark

Let’s price a real workload: 100 million 1536-dimensional vectors (OpenAI text-embedding-3-small output). Each vector takes 1536 × 4 bytes = 6.14KB. 100M vectors = ~614GB of raw float32 data. With HNSW graph overhead (roughly 1.5x the vector data), you need around 900GB of index storage.

Pinecone (serverless, us-east-1)

Pinecone serverless charges per read unit and write unit. At 100M vectors, expect:

• Storage: ~$70-90/month (their pods don’t apply, but serverless has base storage cost)
• Reads: $0.40 per 1M read units; a typical query costs 1-5 read units depending on dimension

At 10M queries/month (a modest production load), you’re looking at $40-200/month in query costs on top of storage. Real production teams with 100M vectors are typically running 50-100M queries/month. That’s $300-800/month in query costs alone.

Total monthly estimate: $400-900/month for 100M vectors at moderate query volume.

Weaviate Cloud (Standard tier)

Weaviate Cloud prices per dimension-hours stored. 100M × 1536 dimensions at their current rates:

• ~$700-1,200/month depending on tier and SLA requirements

Qdrant Cloud

Qdrant Cloud uses cluster-based pricing. A cluster capable of serving 900GB of HNSW index needs at minimum a 3-node cluster with 384GB total RAM:

• Standard compute: ~$800-1,400/month

ManyVector on S3

With ManyVector, your vectors live in S3. You pay:

1. S3 storage: 614GB × $0.023/GB = $14.12/month
2. S3 GET requests: at 10M queries/month, each query fetches ~20-50 objects: ~200-500M GETs = $0.80-2.00
3. ManyVector query fees: per-query pricing, not per-GB

Total storage component: ~$16/month. The ManyVector query layer adds its own cost, but you’re starting from a 40-50x lower base.

Even accounting for the query layer, total cost for 100M vectors at 10M queries/month lands at $60-90/month — roughly 10x cheaper than the incumbents.

Why the architecture difference compounds

It’s not just the storage price. The RAM-first architecture creates several secondary costs:

Replication multiplier. RAM is volatile. You need 3x replication minimum for durability. That triples your RAM cost before you account for any other overhead.

Idle capacity tax. Pinecone, Weaviate, and Qdrant all charge you whether you’re querying or not. Your vectors have to live somewhere in RAM at all times. ManyVector cold namespaces cost nothing at query time — just storage.

Scaling cliff. RAM-based systems have discrete scaling steps. You pay for the next size up before you need it, or you hit an OOM at 3am. Object storage scales to exabytes without a configuration change.

Multi-tenancy complexity. Serving 1,000 customer namespaces in RAM means 1,000 sets of HNSW graphs loaded simultaneously. Object storage-backed systems can serve millions of namespaces because cold namespaces cost nothing until queried.

The latency question

“But won’t object storage be slower?” This is the obvious objection. The answer is: for hot data, no. For cold data, yes, and that’s fine.

A production vector workload has a hot/cold split. The namespaces your users are actively querying today represent a fraction of your total stored data. ManyVector keeps hot namespaces in a warm cache at the query layer. Cold namespaces get fetched from S3 on first access — that first query takes longer, subsequent queries are cached.

For a typical SaaS product with tens of thousands of users, the active namespace set on any given hour is small enough to fit in cache. The long tail of inactive namespaces costs you S3 prices only.

Benchmark numbers on hot namespaces:

• p50 latency: 8-12ms (HNSW traversal, in-cache)
• p99 latency: 25-40ms
• Cold namespace first-fetch: 200-800ms (one-time, then cached)

These numbers are competitive with managed vector databases for hot workloads and dramatically cheaper for mixed hot/cold workloads.

When the incumbents win

To be fair about it: if you have a single 100M-vector namespace that is queried 24/7 at high QPS, the always-hot model is attractive. You pay the RAM price but you get consistently single-digit millisecond latency with no cold-fetch tail.

If you’re running latency-sensitive real-time applications where even a 200ms cold-fetch is unacceptable for any user, you’ll want to profile your actual namespace access patterns carefully before choosing object-storage-native.

But for most teams — multi-tenant SaaS, RAG pipelines, semantic search, AI agents — the workload has a hot/cold structure. And for that workload, object storage wins on cost by a wide margin.

The data sovereignty argument

The cost argument is enough on its own. But there’s a second argument that matters to an increasing number of teams: you don’t control where your vectors live with managed vector databases.

With ManyVector, your vectors go into your S3 bucket. You set the bucket policy. You control the KMS key. Your vectors never transit our infrastructure at write time. When you delete a namespace, you delete it from your bucket — no retention, no backups on our side.

For healthcare teams (HIPAA), financial teams (SOC 2, FedRAMP), and defense teams (FedRAMP High, IL4+), this matters as much as the cost.

Conclusion

The 10x cost reduction isn’t a marketing claim — it’s the direct consequence of swapping RAM for object storage as the persistence layer. The architectural insight is simple: object storage has gotten fast enough, and managed vector databases have gotten expensive enough, that the trade-off has inverted.

If you’re paying more than $100/month to store 100M vectors, it’s worth running the numbers on an object-storage-native approach.