Choosing a vector database on AWS: the RAG-infrastructure decision, on real cost, latency, and ops burden.

IWhat a vector database actually does — and why the choice is a cost/latency tradeoff, not a feature contest

Before comparing six products, fix the mental model. A vector database does one core job, and once you understand that job, the differences between the options stop looking like a feature checklist and start looking like what they really are: different points on a cost, latency, and operational-burden curve.

A vector database stores embeddings — high-dimensional numeric arrays (commonly 256 to 1,536 dimensions, depending on the embedding model) that represent the meaning of a chunk of text, an image, or other content. Its core job is approximate nearest-neighbor (ANN) search: given a query vector, return the k most similar stored vectors, fast, without comparing against every vector in the corpus by brute force. Almost every implementation does this with a graph index called HNSW (Hierarchical Navigable Small World) or an IVF (inverted-file) variant. The algorithm is largely commoditized; what differs is how each product packages, prices, and operates it.

In a retrieval-augmented generation (RAG) system, the vector database is the retrieval half. You embed your documents once (offline), store the vectors, and at query time you embed the user question, ask the vector store for the most similar chunks, and pass those chunks to the model as grounding context. The vector store never talks to the language model directly — it is plumbing that decides which of your documents the model gets to read. That makes it both load-bearing (bad retrieval is the number-one cause of bad RAG answers) and, in cost terms, a line item that runs 24/7 whether or not anyone is querying.

Two properties beyond raw similarity search separate a toy from a production store. First, metadata filtering: the ability to constrain a search to vectors matching structured attributes — tenant ID, document type, date range, access-control labels — ideally as a pre-filter (narrow the candidate set before the ANN search) rather than a post-filter (search first, then throw away results), because post-filtering can return too few results or none. Multi-tenant SaaS, permissioned document search, and any "search only my org's data" requirement live or die on filtering quality. Second, hybrid search: combining dense vector similarity with sparse keyword (BM25) matching, which materially improves recall on queries with exact terms, product codes, names, or acronyms that pure semantic search fumbles.

Hold those two properties — filtering and hybrid search — alongside three cost-and-ops realities, and you have the entire decision. The realities: a vector index is memory-hungry (HNSW graphs largely live in RAM, so cost scales with corpus size whether you query or not); it usually runs continuously (idle cost is real); and someone has to operate it (provisioning, scaling, patching, backups) unless you pay a managed service to do that for you. Every option below is a different bargain across those three. The rest of this guide prices each bargain.

IIThe six real options on AWS in 2026

These are the vector stores a team building on AWS actually chooses between in 2026. Each gets an honest profile: what it is, where it shines, where it hurts, and the cost mechanic that matters. Read this section for the shape of each option; the next sections price and rank them.

A note on scope: this guide covers the stores that integrate cleanly into an AWS-native RAG stack and that Amazon Bedrock Knowledge Bases can use as a backend (with one deliberate exception, Redis, noted below). Self-hosting a dedicated vector engine like Milvus, Weaviate, Qdrant, or Chroma on EC2/EKS is a viable seventh path, but it trades managed simplicity for full operational ownership and is justified by the same narrow conditions as any self-host decision — extreme scale economics or a specific feature need — so it is mentioned but not the focus.

IIICost — the dimension that decides most choices (and the OCU trap in detail)

Cost is where vector-database choices go wrong most often, because the pricing models are not comparable apples-to-apples: one bills fixed compute units, one bills database capacity that scales with load, one bills storage plus queries, one bills as a SaaS subscription. Translate them all into "what does this cost for my corpus and my traffic" and the decision usually makes itself.

The structural divide is between floor-based and usage-based pricing. A floor-based store (a classic OpenSearch Serverless collection, with its OCU minimum) costs roughly the same whether you store a thousand vectors or a million low-volume ones; the floor dominates small workloads. A usage-based store (S3 Vectors; Aurora Serverless v2 scaling down; Pinecone serverless) lets cost track actual storage and queries, so small workloads stay cheap and you pay more only as you grow. The single biggest cost mistake in AWS RAG is putting a small or early-stage workload on a floor-based store.

IVLatency, scale, and filtering — matching the store to the workload

Cost narrows the field; latency, scale, and filtering finish the decision. These are workload requirements, not vendor virtues — the question is never "which is fastest?" but "which clears the bar my workload actually sets?" Over-buying performance you do not need is just a more expensive way to be wrong.

Set your real targets before you shop. Most RAG question-answering is comfortable with retrieval in the tens-to-low-hundreds of milliseconds, because the language-model generation step that follows takes far longer anyway — shaving 10ms off retrieval is invisible next to a multi-second completion. Real-time recommendation, semantic caching, and personalization in a hot path are different: there, single-digit-millisecond retrieval can be the requirement. Know which world you are in, because it is the difference between "any of these work" and "you need an in-memory store."

VOperational burden and Bedrock Knowledge Bases integration

The store you choose is something your team operates for years, and on AWS most teams are not building a custom retrieval engine — they are pointing Amazon Bedrock Knowledge Bases at a backend and letting it manage chunking, embedding, and retrieval. So two practical questions decide a lot: how much will this cost me in operational time, and does it drop cleanly into Knowledge Bases?

On operational burden, the spectrum runs from "fully managed, near-zero ops" to "you own it." Pinecone (SaaS) and S3 Vectors (it is just S3) sit at the low-ops end. OpenSearch Serverless removes cluster management and autoscales, so it is low-ops despite being powerful — the cost is financial (the OCU floor), not operational. Aurora pgvector is moderate: it is a managed database, but you still own schema, indexing strategy, sizing, and tuning — though if you already run Postgres, that burden is one you have already accepted. Redis/MemoryDB and Neptune Analytics are specialized engines that carry more operational and design weight, justified by their specific strengths.

The Bedrock Knowledge Bases angle is decisive for RAG teams. Knowledge Bases is AWS's managed RAG service: point it at an S3 data source and a supported vector store, and it handles ingestion (chunking + embedding) and retrieval for you. Its supported vector-store backends include Amazon OpenSearch Serverless (the default it will create for you), Amazon Aurora PostgreSQL (pgvector), Pinecone, Amazon Neptune Analytics (for GraphRAG), and increasingly Amazon S3 Vectors. If you want Knowledge Bases to manage your pipeline, choosing from that supported set keeps the integration first-class.

A crucial, money-saving subtlety: when you let Bedrock Knowledge Bases set everything up with defaults, it provisions OpenSearch Serverless, and you can inherit an OCU minimum. That is the right call for a large production knowledge base and the wrong call for a small POC. For small or early Knowledge Bases workloads, explicitly select Aurora pgvector or S3 Vectors as the backend instead of accepting the default. This one configuration choice is the difference between a small RAG POC costing a few dollars a month and costing several hundred.

Redis/MemoryDB is the deliberate exception to the Knowledge Bases path. It is not a first-class Knowledge Bases backend, so teams reach for it when they are building a custom retrieval layer (often for latency-critical or semantic-cache use cases) rather than using managed Knowledge Bases. If your plan is "Knowledge Bases manages my RAG," Redis is usually not the answer; if your plan is "I am hand-building a low-latency retrieval path," it may be exactly the answer.

VIThe five most common (and expensive) mistakes

Most regret in vector-database selection traces to a handful of repeatable errors. Naming them is the cheapest insurance available — each one is easy to avoid once you know it exists, and each one routinely costs teams either real money or weeks of rework.

• Defaulting to OpenSearch Serverless for a small workload: By far the most common and most expensive error. Accepting the Bedrock Knowledge Bases default can put a minimum OCU charge on a POC that has almost no data or traffic. Fix: use Aurora pgvector or S3 Vectors while small; move to OpenSearch when scale and hybrid search justify the floor.
• Choosing on benchmarks instead of your two numbers: Public ANN benchmarks measure raw query speed on synthetic data and rarely reflect your corpus size, query volume, filtering needs, or cost. The decision is driven by your corpus size and QPS (and your ops appetite), not by who wins a leaderboard at a workload that is not yours.
• Ignoring metadata filtering until multi-tenancy breaks it: A store that nails similarity search can still mishandle filtered search — especially post-filtering, which can silently return too few results or leak across tenants. Test filtered, multi-tenant queries (pre-filter behavior, correctness, recall) before committing, not after a customer sees another tenant's data.
• Over-buying latency you do not need: Paying for in-memory single-digit-millisecond retrieval when your RAG generation step takes multiple seconds is spending money to optimize an invisible part of the pipeline. Match latency to the actual requirement; for most RAG, tens of milliseconds is plenty.
• Treating the store as permanent and un-portable: Embeddings are portable — they are just arrays — and Bedrock Knowledge Bases abstracts the backend. You can start on the cheap, correct store for today and migrate when you outgrow it by re-indexing. Do not let fear of lock-in push you into an oversized, overpriced store on day one; pick for now, and keep the embedding pipeline reproducible so re-indexing later is routine.

VIIA reference RAG retrieval stack — and how the store fits

The vector database does not live alone. Seeing where it sits in a complete RAG retrieval flow clarifies which decisions are the store's job and which belong to the layers around it — and prevents the common error of blaming the store for problems that are really upstream.

A production RAG retrieval pipeline has the same shape regardless of which store you pick. Ingestion (offline): source documents in S3 are chunked, each chunk is embedded by an embeddings model (such as Amazon Titan Text Embeddings or Cohere Embed on Bedrock), and the vectors plus their metadata are written to the vector store. Query (online): the user question is embedded with the same model, the vector store returns the top-k most similar chunks (optionally filtered by metadata and fused with keyword results in hybrid search), an optional re-ranking step reorders the candidates for relevance, and the surviving chunks are passed to the language model as grounding context.

The vector store owns exactly two steps in that flow: storing the vectors and returning the nearest neighbors (with filtering/hybrid logic). Everything else — chunking strategy, choice of embedding model, re-ranking, prompt assembly — sits in the layers around it, and most RAG quality problems live in those layers, not in the store. A useful discipline: when retrieval quality is poor, check chunking and embeddings and re-ranking before concluding you chose the wrong database. The store is responsible for being fast, correctly filtered, and affordable; it is not responsible for whether you chunked your documents sensibly.

This is also why store choice is lower-risk than it feels. Because Bedrock Knowledge Bases (or a thin retrieval interface in custom code) sits between your application and the store, swapping backends is a re-indexing job, not a rewrite — the same property called out in the mistakes section. Pick the store that fits your corpus size, QPS, latency, filtering, and budget today; keep the ingestion pipeline reproducible; and treat the store as a component you can upgrade, not a one-way door.

VIIIDecision table — pick by corpus size and query volume

The whole guide collapses into this: find your row by corpus size and column by query volume, and read the recommended store. These are starting points for the common cases, not absolute laws — adjust for a hard latency requirement (push toward Redis/MemoryDB), heavy hybrid-search needs (push toward OpenSearch), or a graph-shaped corpus (Neptune Analytics).