S3 Vectors is a vector store that bills like object storage. You pay for what you keep and what you query. No cluster to size, no node to keep warm, no idle bill at 3am. For most RAG projects starting out, that is the right default. This post says when it fits and when it does not.
What it actually is
S3 Vectors stores embeddings in a bucket and runs nearest-neighbor search over them. You write vectors with metadata. You query by vector and filter on metadata. AWS handles the index. There is no server you provision.
The model is closer to DynamoDB on-demand than to a database cluster. Cost tracks storage and request volume. A corpus that sits quiet most of the day costs almost nothing while it sits.
Why it works as a default
Most early RAG corpora are small and queried in bursts. A support knowledge base. Internal docs. A product manual. You are talking tens of thousands of chunks, not hundreds of millions. Traffic is human-paced, not machine-paced.
For that shape, a dedicated vector cluster is overkill. You provision nodes, pay for them around the clock, and use a fraction of the capacity. The bill arrives whether anyone searched or not. We see this same pattern in compute too. Most AWS bills hide 30-60% in savings, and idle vector infrastructure is a common offender.
S3 Vectors removes the idle line item. You write your chunks once. You query when a user asks a question. The economics match the usage. That is the whole pitch.
Where it fits cleanly
It fits when latency tolerance is in the hundreds of milliseconds, not single digits. A chatbot answering a question can spend 200ms on retrieval. Nobody notices. A support agent we built answers in 12 minutes, down from 4 hours, and retrieval time is a rounding error in that.
It fits when your corpus is under a few million vectors. It fits when query volume is bursty or low. It fits when you would rather not run infrastructure for a feature that might still get cut.
It fits when cost predictability matters more than peak speed. You can model the bill from storage size and expected queries. No capacity planning meeting required.
Where it does not fit
It does not fit when you need single-digit-millisecond retrieval under constant load. High-QPS production search wants a warm index in memory. S3 Vectors is not built for that, and forcing it there is the wrong call.
It does not fit at very large scale with heavy concurrent traffic. Once you are at hundreds of millions of vectors and steady high QPS, a dedicated store earns its keep. The math flips. The idle cost you were avoiding becomes utilization you are actually using.
It does not fit when you need exotic index tuning. If you are hand-tuning HNSW parameters for a specific recall-latency tradeoff, you want a store that exposes those knobs. S3 Vectors trades that control for simplicity.
How to decide
Start with three questions. How many vectors? How fast must retrieval be? How constant is the load?
Small corpus, sub-second latency, bursty load: use S3 Vectors. You will spend less and run nothing. Large corpus, millisecond latency, steady load: use a dedicated store and accept the operational cost. Most teams starting a RAG project are in the first bucket and assume they are in the second.
The mistake we see is over-provisioning on day one. A team stands up a vector cluster for a corpus that would fit comfortably in S3 Vectors, then pays cluster prices for chatbot traffic. The cheaper default would have carried them through launch and well past it.
What we do
We build RAG systems on the store that matches the workload, not the store that looks impressive in a diagram. For most early builds, that is S3 Vectors. When the numbers say otherwise, we say so and move to a dedicated store. You get a fixed price either way, you own the code, and we exit when it ships.
Our RAG Chatbot work is scoped and priced before we start. No open-ended hourly meter. See pricing for the bands.
If you are weighing a vector store for a RAG build and want a second read on the tradeoff, book a call. It is a free 30-minute conversation, no pitch required.