Bedrock Knowledge Bases: Pick the Right Vector Store
Amazon Bedrock Knowledge Bases supports 8 vector stores. A builder's decision framework for OpenSearch vs S3 Vectors vs Aurora—and how to cut RAG cost.
Series: Best Practices (7 articles)
- …
- 7Bedrock Knowledge Bases: Pick the Right Vector Store This article
Lead Data Scientist
Bedrock Knowledge Bases: Pick the Right Vector Store
The fastest way to burn $300 a month on a RAG proof-of-concept nobody's querying yet is to click "Quick create" in Amazon Bedrock Knowledge Bases and walk away.
That button spins up an Amazon OpenSearch Serverless collection, which is a fine production vector store — and also one that bills a two-OCU minimum at roughly $0.24/OCU-hour whether you send it a million queries or zero. That's about $345/month as a floor, before you've indexed a single useful document. For a demo, a hackathon, or an internal tool that gets ten questions a day, you're paying for a Ferrari to sit in the garage.
The good news: Bedrock Knowledge Bases now supports eight vector stores, and the choice genuinely matters for cost, latency, and even the kind of retrieval you can do. Here's how I actually decide.
The lineup
Bedrock's supported vector stores fall into three buckets:
- AWS-native, serverless-ish: Amazon OpenSearch Serverless (the quick-create default) and Amazon S3 Vectors (GA since December 2025).
- AWS-native, you-manage-capacity: Amazon OpenSearch Managed Cluster, Amazon Aurora PostgreSQL with
pgvector, and Amazon Neptune Analytics (for GraphRAG).
- Third-party: Pinecone, Redis Enterprise Cloud, and MongoDB Atlas.
Most teams should be choosing from the first two buckets unless they already run one of the third-party stores.
A decision framework
Instead of memorizing a matrix, ask four questions in order:
1. How often will this index actually be queried? If the answer is "rarely" — POCs, internal knowledge tools, archival corpora — reach for Amazon S3 Vectors. It's purpose-built for infrequent query workloads, charges for storage and requests rather than always-on compute, and AWS positions it at up to ~90% lower cost than the default store for these patterns. Latency is sub-second for cold queries and can drop toward ~100ms under steady traffic. The tradeoff: it stores float32 embeddings only (no binary vectors), and metadata is capped at 1 KB and 35 keys per vector, which matters if you lean hard on hierarchical chunking.
2. Do I need consistently low latency at high QPS? For customer-facing search or chat with real traffic, OpenSearch Serverless (or a Managed Cluster if you want to size and pin capacity yourself) earns its always-on cost. It's also the only option that supports binary vector embeddings, which cut storage and speed up similarity math if your embedding model emits them.
3. Am I already running the data layer? If your app already lives on Aurora PostgreSQL, adding
pgvector is often the pragmatic, cheapest path: no new service, HNSW indexing, and hybrid (keyword + vector) search in one query. Just note the operational fine print — enable HNSW iterative index scans ( pgvector 0.8.0+) so metadata filters don't silently under-return results, and put a GIN index on your metadata column.4. Are relationships part of the answer? If retrieval quality depends on connections — "which policies cite this clause," multi-hop questions — Neptune Analytics gives you GraphRAG: a graph plus a vector index, created together. It's a different retrieval model, not just a cheaper box.
The config is nearly identical
One underrated point: switching stores is mostly a
storageConfiguration change, not an application rewrite. Pointing a knowledge base at S3 Vectors in boto3 looks like this:python
Python
import boto3bedrock_agent = boto3.client("bedrock-agent")kb = bedrock_agent.create_knowledge_base(name="docs-kb",roleArn="arn:aws:iam::123456789012:role/BedrockKBRole",knowledgeBaseConfiguration={"type": "VECTOR","vectorKnowledgeBaseConfiguration": {"embeddingModelArn": ("arn:aws:bedrock:us-east-1::foundation-model/""amazon.titan-embed-text-v2:0")},},storageConfiguration={"type": "S3_VECTORS","s3VectorsConfiguration": {"indexArn": ("arn:aws:s3vectors:us-east-1:123456789012:""bucket/my-vector-bucket/index/my-vector-index")},},)print(kb["knowledgeBase"]["knowledgeBaseId"])
Swap that
storageConfiguration block for OPENSEARCH_SERVERLESS or RDS and the rest of your ingestion and retrieve / retrieveAndGenerate code doesn't move. Two things to keep aligned: the embedding model's output dimensions must match the vector index (Titan V2 supports 1024/512/256), and the knowledge base's IAM role needs access to the specific store's API plus the embedding model.Why this matters / what I'd do
My default playbook:
- Prototyping or infrequent internal RAG → start on S3 Vectors. Let the bill scale with actual use, not clock time.
- Production, high-traffic, or binary embeddings → OpenSearch Serverless, sized deliberately.
- Already on Postgres → Aurora + pgvector, and skip the new service entirely.
- Relationship-heavy corpora → Neptune Analytics GraphRAG.
The meta-lesson: the "Quick create" default optimizes for AWS's demo, not your cost curve. Because the store is a swappable config, treat it as a deliberate architecture decision you can revisit as query volume grows — start cheap, then graduate to always-on compute when traffic justifies it.
What's your default vector store for a brand-new Bedrock knowledge base — and has S3 Vectors changed that calculus for you yet?
#AWS #Bedrock #RAG #GenAI #MachineLearning #VectorSearch #CloudArchitecture
Series: Best Practices (7 articles)
- …
- 7Bedrock Knowledge Bases: Pick the Right Vector Store This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article