Three products, one bet: your embeddings do not belong in RAM. Amazon S3 Vectors, Turbopuffer, and LanceDB all read vectors off object storage instead of paying to keep billions of them hot in memory — and that single design choice is what cuts retrieval bills by an order of magnitude. The question a founder actually has to answer isn't whether to move embeddings onto cheap storage. It's how much query latency you'll trade to do it, and where you want the compute to live.

The short version: S3 Vectors is the cold, huge, cheap tier — up to 2 billion vectors per index and AWS's claim of up to 90% lower cost than specialized databases, in exchange for query latency in the hundreds of milliseconds. Turbopuffer puts a caching and serving layer over object storage so warm queries stay fast — the pick for multi-tenant SaaS that needs cheap per-tenant isolation. LanceDB runs embedded in your own process on the Lance columnar format — the pick for developer ergonomics, local dev, and versioned RAG evals. Same thesis, three buyers.

The bet they all share#

For two years the default vector database — Pinecone, Qdrant, Weaviate in its hot mode — kept your index in memory because that's how you get single-digit-millisecond search. It's also why the retrieval line on a RAG bill scales with the size of your corpus whether or not anyone queries it. Every embedding you store is RAM you rent, forever.

Object-storage-native retrieval breaks that link. Vectors sit on S3-class blob storage priced in fractions of a cent per gigabyte; compute reads them on demand. The cost of storing a billion embeddings you rarely touch drops toward the cost of storing a billion of anything else. What you give back is latency — reading from object storage is slower than reading from RAM — and the entire product story of these three is how they hide that latency. That's the axis to compare on. (We walked the in-memory incumbents in pgvector vs Pinecone vs Qdrant; this piece is about the tier below them.)

S3 Vectors — cold, enormous, and cheap#

Amazon S3 Vectors went generally available on December 2, 2025, holding up to 2 billion vectors per index and up to 10,000 indexes per vector bucket, and AWS pitches it at up to 90% lower total cost to upload, store, and query than specialized vector databases. It has since expanded to 17 more regions (March 2026) and reached GovCloud (July 2026) — the boring-infrastructure signal that it's a default, not an experiment.

The catch is stated plainly by its own positioning: this is cost-and-scale storage, not a low-latency index. Expect queries in the hundreds of milliseconds. That's fine — often ideal — for a large knowledge base queried occasionally, for archival embeddings, or for cost-sensitive RAG where a beat of latency is invisible next to model inference. It's the wrong tool for a typeahead. If you're already on AWS and your corpus is huge, S3 Vectors is the cheapest managed way to hold it.

Turbopuffer — object storage that stays warm#

Turbopuffer takes the same durable-storage-on-blob foundation and adds a caching and serving layer so that warm namespaces answer in low single-digit milliseconds while cold data still costs object-storage prices to keep. Its sweet spot is multi-tenant products: one namespace per customer, thousands of them, most idle at any moment, and you're not paying in-memory rates for the long tail. If you're building SaaS where each tenant needs isolated retrieval and the economics only work if idle tenants are nearly free, this is the shape that was designed for you. We compared it head-to-head with the incumbents in Turbopuffer vs Pinecone vs Vectorize and LanceDB vs Turbopuffer for agent retrieval.

LanceDB — the database that runs inside your process#

LanceDB is the odd one out in the best way: it's embedded. It runs in-process on the Lance columnar format, reading directly from local disk or object storage with no server to operate. That buys you the fastest local development story here, native hybrid search, and — because Lance is versioned — the ability to branch a table for reproducible RAG evals, which is genuinely hard to do on a managed service. The tradeoff is that scale and latency are bounded by the compute you give the process, and remote-storage cold reads are slower than a warm cache. For a solo builder who wants to move fast without operating anything, it's the lowest-friction start; we detailed the eval workflow in LanceDB table branching for reproducible RAG evals.

The decision, and the pattern that beats it#

Pick on latency budget and where compute lives:

But the highest-leverage move is often not to pick one and force it to do everything. The production pattern that keeps winning is to tier: park the bulk of your embeddings on the cheap object-storage store, and promote the hot working set into a low-latency layer — which is exactly why warming a vector cache from object storage stopped being a footnote and became part of the retrieval design. Cheap storage and fast serving aren't competing choices anymore. They're two tiers of the same stack, and the founders who ship the fastest retrieval on the smallest bill are the ones who stopped treating them as either/or.