Choosing a vector store for RAG by query volume, not vector count

Most teams choose a vector database by asking how many vectors they have. That is the wrong first question. Storage for even a few hundred million vectors is cheap on every option. What changes your bill, and your latency profile, is how often you query them and how spiky that traffic is.

This post is a decision framework for RAG systems on AWS or near it. It compares four common choices: Amazon S3 Vectors, Amazon OpenSearch Serverless, Aurora PostgreSQL with pgvector, and Pinecone. Cost figures come from one public cost model, cited below, so treat them as an illustration of shape rather than a quote for your workload.

Why the vector count misleads

A vector store bill has roughly three parts: storage, writes, and queries. The stores price these very differently:

• S3 Vectors charges for logical GB uploaded, logical GB stored, and queries (a per-API fee plus a per-TB fee tied to index size), per the AWS launch post for general availability. Nothing runs when nobody queries.
• OpenSearch Serverless charges for compute capacity (OCU-hours) whether or not you are busy, with scale-to-zero on newer collection types.
• Aurora pgvector charges for provisioned or serverless compute (ACU-hours) plus storage.
• Pinecone charges by read and write units, with a monthly minimum on its standard plan.

So S3 Vectors is closest to "pay per question", OpenSearch and Aurora are "pay for capacity", and Pinecone sits in between. Which is cheaper depends on how many questions you ask.

What the numbers look like

A public cost model by Darryl Ruggles prices these four stores for 1024-dimension float32 vectors with 1 KB of metadata, using us-east-1 prices from May 2026. It is a single author's model, not a vendor benchmark, but it shows the pattern well. Monthly figures for two of its scenarios:

Same data, same size. The cheapest option at 10K queries a month is the most expensive at 10M. The author's crossover analysis at 100M vectors puts S3 Vectors cheapest between roughly 1K and 100K queries a month, Pinecone in the 1M to 2.5M band, and Aurora pgvector from about 5M a month upward, as long as the index fits in memory.

The same post notes that Aurora capped at 16 ACUs makes its large-index numbers optimistic, because an HNSW index for 100M+ vectors will not fit in that memory. Read the table as direction, not as a purchase order.

Latency and cold starts are the other half

Cost is not the only axis. The same author measured warm and cold latency on a small 50K-vector index in a single run on 2026-05-30:

Those include roughly 50 ms of client overhead, and the Pinecone numbers cross the public internet. One run on a small index is a weak benchmark, so measure your own. But the cold-start gap matters for a chatbot: a 15-second first answer after a quiet period is a product bug, not a tuning detail.

AWS itself describes S3 Vectors as returning infrequent queries in under a second and frequent queries in around 100 ms or less, and supporting up to 2 billion vectors per index, in its launch post.

A decision framework

Answer these in order.

1. How many queries per month, at peak and on average? Under about 100K: start with S3 Vectors. In the low millions: compare Pinecone and a managed Postgres. Above that: a store you pay for by capacity.
2. Is traffic bursty or steady? Bursty and quiet most of the day favors pay-per-query. Steady load favors reserved capacity, where the per-query cost falls as utilization rises.
3. Do you need hybrid search or SQL joins? If retrieval needs metadata joins, row-level permissions or transactional consistency with your app data, pgvector keeps it in one database. If you need keyword plus vector ranking, OpenSearch is built for that.
4. What is your cold-start tolerance? Internal tools forgive a slow first query. Customer-facing chat does not.
5. How fast will the corpus change? S3 Vectors supports streaming single-vector updates (AWS cites up to 1,000 PUTs per second), but heavy re-indexing patterns deserve a test before you commit.

Plan for a migration, because usage will change

The pattern we would recommend is to treat the store as replaceable. Keep your chunking, embedding model and metadata schema in your own code, and put a thin interface in front of the store:

from typing import Protocol

class VectorStore(Protocol):
    def upsert(self, items: list[dict]) -> None: ...
    def query(self, vector: list[float], k: int, filters: dict | None = None) -> list[dict]: ...
    def delete(self, ids: list[str]) -> None: ...

Then store the raw text and metadata in object storage or Postgres as the source of truth. With embeddings reproducible from that source, switching stores is a re-index job, not a rewrite. In earlier work on RAG pipelines over Pinecone, ChromaDB and Weaviate, the stores differed mainly in filtering behaviour and operational overhead, and a thin interface kept those differences out of application code.

Also log queries per day from the first week. The crossover points above only help if you know which side of them you are on, and a prototype at 2K queries a month can quietly become a product at 2M.

The practical takeaway

Pick the cheapest store for the query volume you have now, put an interface in front of it, and set a calendar reminder to re-run the cost comparison when monthly queries grow by 10x. Verify the pricing with your own region and vector dimension before you decide, since every figure here depends on those assumptions.