S3 Vectors vs OpenSearch Serverless: picking a vector store | Agentic ERP Quickstart
For a small corpus that sits idle, S3 Vectors removed infrastructure OpenSearch Serverless required. The workload signals that should reverse the decision.
Series: Building Production-Grade ERP Agents on AWS (18 articles)
- …
- 18S3 Vectors vs OpenSearch Serverless: picking a vector store | Agentic ERP Quickstart This article
S3 Vectors vs OpenSearch Serverless: picking a vector store | Agentic ERP Quickstart
Most vector store comparisons argue about retrieval quality, which is the wrong argument for most workloads, because nearly every option can return similar documents. The question that actually decided this one was how much infrastructure has to stay configured while the corpus sits idle. This project moved its Amazon Bedrock knowledge bases from OpenSearch Serverless to Amazon S3 Vectors on that basis alone, and the reasoning inverts cleanly: name the workload signals that make the operating model stop mattering, and you have named the conditions under which you should go back.
Series: Building governed ERP agents on AWS · Series guide →
This post: The vector-store decision behind the sample's knowledge bases, stated as an operating-model trade rather than a performance claim.
Prereq: None. The agentic SOP model covers the procedures this knowledge base stores, if you want that background first.
IMPORTANT
This is an operating-model fit judgment for a small, low-traffic corpus. It is not a benchmark, a latency comparison, a price quote, or a claim that one service beats the other.
New to this series? Start here
The Agentic ERP Automation Quickstart is an open source reference implementation that deploys an AI agent for work your team does by hand from a written procedure, on Amazon Bedrock AgentCore. Accounts payable is the worked example, where a case looks like an invoice that does not match its purchase order. A new process type is a skill directory and your own SOPs. Six terms recur below:
- An SOP is a standard operating procedure: the written steps for resolving one kind of exception. The agent reads it.
- An embedding turns text into a list of numbers so that similar text lands close together. A vector store holds those numbers and answers similarity queries.
- A Bedrock knowledge base is the managed service that ingests your documents, creates embeddings, and answers retrieval requests.
- QPS means queries per second. Low-QPS here means a corpus that is idle most of the time.
- Chunking is how a document gets split before embedding. Whole-document ingestion means it is not split.
- AOSS is Amazon OpenSearch Serverless, the store this design moved away from.
Two corpora, one retrieval need
The sample needs retrieval over two different bodies of text:
| Corpus | What it is for |
|---|---|
| SOPs | Supporting ERP exception processing |
| API documents | SAP service discovery |
Both need the same four things: a document source, embeddings, an index, and a retrieval interface.
The earlier design used OpenSearch Serverless. Its operational shape included index creation, security-policy configuration, consistency waits, and a separate storage deployment path. For plenty of retrieval workloads that is a fair trade. For a low-QPS sample it was more infrastructure than the job required.
Select for the operating model, not just the query
It is tempting to evaluate a vector store by asking one question: can it return similar documents? Nearly all of them can.
The more useful questions are about the operating model:
- How much infrastructure has to stay configured while the corpus sits idle?
- How many custom resources does someone have to operate?
- What filtering does the retrieval path actually need?
- How much query traffic does the application have to sustain?
For this reference architecture, those answers pointed at S3 Vectors, and the move reduced the number of repository-managed storage components. Note the scope of that statement. It does not establish current savings, measured lower latency, or feature parity with OpenSearch.
What the deployment creates
The CDK configuration creates two vector buckets and two indexes, one for SOPs and one for API documentation. Each index uses
float32, 1024 dimensions, and cosine distance, with Bedrock-managed metadata keys. The default embedding model is Amazon Titan Text Embeddings v2.
The source document bucket and the vector bucket are deliberately separate resources. Bedrock knowledge bases ingest from the source bucket and use the S3 Vector index as storage. The knowledge base resource declares
S3_VECTORS directly.IMPORTANT
The 1024-dimension setting belongs to the selected default embedding model. It is not a general recipe. If you change the embedding model, expect to match the index dimensions and to plan a validated re-ingestion.
Keep the application boundary stable
The part of this design that ages well is the interface, not the store.
The retrieval caller does not know or care what the vector-store type is. The deployment writes stable AWS Systems Manager parameters holding the SOP and API-document knowledge-base IDs. The knowledge-base Lambda function reads those IDs and calls the Bedrock
retrieve operation.
That gives you two things. The backing store can change without every caller learning a new database query API. And retrieval stays separate from the agent's process routing, so the primary SOP path can use its routed procedure while the knowledge base handles focused loading and supplementary search.
When this answer is the wrong one
S3 Vectors was chosen here for a lower-infrastructure, often-idle posture. Some specifics of the current setup are worth knowing before you copy it:
- The two Bedrock metadata keys are not filterable in the current index configuration.
- The SOP search path runs an unfiltered semantic query.
- The two corpora are chunked differently on purpose. SOPs default to whole-document ingestion. API documents keep Bedrock default chunking, which suits passage-oriented retrieval.
Evaluate OpenSearch Serverless or OpenSearch Managed when evidence from your own workload shows you need low latency, high query throughput, richer filtering, or database-specific search capabilities.
Do that evaluation with your real inputs: the Region, the corpus size, the chunking strategy, the concurrency, the query mix, and an actual cost model. Do not inherit this decision from a sample whose corpus is nothing like yours.
What the move does not remove
Switching stores removed the earlier AOSS index custom resource and storage-stack path. It removed nothing else.
You still own ingestion, AWS Identity and Access Management permissions, source-document publication, embedding-model compatibility, and failure handling. After any deployment, an operator still has to confirm that both corpora ingest and retrieve correctly.
WARNING
Cost language needs the same discipline as performance language. The design decision record's cost motivation is historical, not a current price quote, an all-in bill, or a benchmark. Any published money claim needs a dated pricing source, a Region, stated workload assumptions, and cost-owner review.
Trade-offs
- What you gain. A declarative backing store and fewer repository-managed storage components for a low-QPS corpus.
- What you give up. Filtering and search capabilities that a search-engine backing store provides, and the option to lean on them later without a migration.
- What the design does not promise. Lower cost, lower latency, or feature parity. Those need your own dated, workload-specific evidence.
Match the store to the workload
Choose the vector store that matches your workload and your ownership model. For this low-QPS reference architecture, S3 Vectors makes the backing store declarative and drops an operational path the sample did not need.
For a workload with real query volume and real filtering requirements, the same reasoning lands somewhere else. That is the point: the reasoning travels, the answer does not.
Where to go next
- Which agent changes need a deployment . How SOP content reaches this knowledge base.
- How an agent loads its procedure . Why routed loading and semantic search stay separate.
- Deploy an AI agent for SAP exception handling . Stand up an environment and inspect the indexes yourself.
Series: Building Production-Grade ERP Agents on AWS (18 articles)
- …
- 18S3 Vectors vs OpenSearch Serverless: picking a vector store | Agentic ERP Quickstart 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