When you build RAG on Amazon Bedrock Knowledge Bases, one decision shapes cost, latency and operations more than almost any other: the vector store. The two most common choices are Amazon OpenSearch Serverless and Aurora PostgreSQL with pgvector. The short answer: OpenSearch Serverless for large-scale, search-heavy workloads; Aurora pgvector when your data already lives in Postgres and scale is moderate. This guide compares them on the dimensions that actually decide production RAG.
The two options
- Amazon OpenSearch Serverless — a purpose-built, fully managed search and vector engine. It scales capacity automatically, supports approximate nearest-neighbor vector search plus rich keyword search, and is designed for large corpora and hybrid retrieval.
- Aurora PostgreSQL + pgvector — the
pgvectorextension adds vector similarity search to a familiar relational database. Vectors live next to your relational data, so you query both with SQL and get Postgres transactions, backups and tooling.
Both are supported targets for Bedrock Knowledge Bases; Bedrock manages ingestion and querying against whichever you configure. For the full RAG pipeline see build and troubleshoot Bedrock RAG.
Comparison
| Dimension | OpenSearch Serverless | Aurora pgvector |
|---|---|---|
| Type | Purpose-built search/vector engine | Relational DB with vector extension |
| Scale | Large corpora, auto-scaling | Small–moderate; scales with instance sizing |
| Hybrid search | Strong native keyword + vector | Possible via SQL + full-text, more manual |
| Data co-location | Separate store | Vectors beside relational data |
| Filtering | Rich metadata filtering | Native SQL WHERE filters |
| Ops familiarity | Managed, search-oriented | Familiar Postgres for most teams |
| Cost shape | Managed capacity units | Aurora instance/serverless cost |
Scale and performance
At large corpus sizes and high query volume, a purpose-built engine like OpenSearch Serverless tends to scale and perform more predictably — it's built for approximate nearest-neighbor search and auto-scales capacity. Aurora pgvector performs well at small-to-moderate scale; as vectors grow into the many millions, you manage index type/parameters and instance sizing more actively to hold latency down. Match the choice to your realistic corpus size, not a hypothetical.
Filtering and hybrid search
Metadata filtering is essential for multi-tenant or multi-product RAG (so retrieval doesn't cross boundaries). OpenSearch offers rich native filtering and strong hybrid search (combine keyword and vector for better precision on names, codes and exact terms). With pgvector you get filtering "for free" as SQL WHERE clauses and can combine with Postgres full-text search, though hybrid ranking is more hand-built. If hybrid search is core to quality, OpenSearch has the edge.
Data co-location and simplicity
If your source data already lives in Aurora/Postgres, pgvector is compelling: vectors sit beside the relational rows, one database backs up and secures both, and your team already knows the tooling. That operational simplicity is a real advantage for moderate-scale apps and often outweighs raw search features.
Cost
Neither is universally cheaper — it depends on corpus size and query volume. OpenSearch Serverless bills by managed capacity; Aurora bills by instance or serverless capacity. For a small RAG app on data already in Aurora, adding pgvector avoids a second system entirely. For a large, search-heavy corpus, OpenSearch's scaling usually justifies its cost. Model both against your real data volume and QPS.
How to choose
- Pick OpenSearch Serverless if: large corpus, high query volume, hybrid (keyword + vector) search matters, or you want a purpose-built managed vector engine.
- Pick Aurora pgvector if: your data already lives in Postgres, you want vectors co-located with relational data and transactions, scale is moderate, and operational simplicity wins.
Both integrate cleanly with Knowledge Bases, so this is a reversible decision for many teams — but re-embedding and re-ingesting to switch stores isn't free, so choose deliberately. For hands-on help see Bedrock Knowledge Bases support, and the commercial deep dive at OpenSearch vs pgvector job support.
Interview implications
"Which vector store would you use for this RAG system and why?" is a common AWS GenAI interview question. The strong answer names the deciding factors — scale, existing data location, hybrid-search need, operational preference — and maps them, rather than declaring a favorite. Prep with Bedrock interview questions.
Frequently asked questions
What vector database works with Bedrock Knowledge Bases?
Several, most commonly OpenSearch Serverless and Aurora pgvector; Bedrock manages ingestion and querying against whichever you configure.
Should I use OpenSearch or pgvector?
OpenSearch for large-scale, search-heavy, hybrid workloads; pgvector when data lives in Postgres and scale is moderate.
Is pgvector good enough for production?
Yes for many small-to-moderate workloads; at very large scale or heavy hybrid search, a purpose-built engine scales more predictably.
Related resources
- RAG build: Build & troubleshoot Bedrock RAG · Bedrock RAG guide
- Managed vs custom: Knowledge Bases vs custom RAG
- Support: Knowledge Bases support · Bedrock RAG job support
Choosing a vector store for a real RAG system?
Our AWS AI engineers help you pick and implement the right store, tune retrieval, and ship production RAG. Explore Amazon Bedrock RAG job support or message us: WhatsApp +91 96606 14469.