How to Pick a Vector Store for Bedrock Knowledge Bases
AWS breaks down three vector store options for Bedrock RAG apps, with benchmarks across real use cases. The choice has direct consequences for speed and cost.
Edited by Reha Talu ·
When building a retrieval-augmented generation application on Amazon Bedrock, the vector store sitting beneath it is not a neutral infrastructure decision. It shapes retrieval latency, indexing cost, and how well the system scales under load. AWS has published a comparative breakdown of three options available within Bedrock Knowledge Bases: Amazon OpenSearch Service, Amazon Aurora PostgreSQL with pgvector, and the newer Amazon S3 Vectors.
What Each Option Brings to the Table
OpenSearch Service is the most established of the three. It offers dedicated vector indexing, strong approximate nearest-neighbor search performance, and a mature operational surface. For teams already running OpenSearch for search or logging workloads, consolidating on it for vector storage avoids another service to manage.
Aurora PostgreSQL with pgvector takes a different approach. It layers vector search onto a relational database, which makes it a practical fit for applications where structured data and vector queries need to coexist. The trade-off is that PostgreSQL was not purpose-built for vector workloads, so performance at scale requires careful tuning of indexes and query plans.
S3 Vectors is the newest entrant and the most cost-oriented. Object storage costs considerably less per gigabyte than managed database or search services, which matters when storing large volumes of embeddings that are queried infrequently. The latency profile will differ from the other two options, making it better suited to batch or lower-frequency retrieval scenarios than to real-time chat applications.
Three Use Cases, Different Winning Configurations
The AWS post structures its comparison around three distinct RAG patterns rather than synthetic benchmarks alone. This is the more useful framing. A customer support assistant hitting the vector store hundreds of times per minute has fundamentally different requirements than a document summarization pipeline running overnight.
For high-concurrency, low-latency retrieval, OpenSearch Service holds an advantage because its vector engine is optimized for exactly that access pattern. For mixed workloads where relational filtering accompanies vector search, pgvector inside Aurora reduces the round-trips between services. For cost-sensitive archival or knowledge base scenarios where retrieval happens at moderate frequency, S3 Vectors offers a meaningfully lower operating cost floor.
Why the Selection Framework Matters More Than the Benchmarks
Raw benchmark numbers tend to reflect the conditions of the test rather than production reality. What carries more weight here is the decision framework AWS pairs with the data. Developers are prompted to assess query frequency, acceptable latency thresholds, whether metadata filtering is required, and total data volume before picking a store.
This criterion-based approach is practical because it forces a conversation about workload shape before committing to infrastructure. Vector stores are not trivially swappable once an application is in production, so getting this decision right during the design phase avoids expensive migrations later.
The open question for teams evaluating S3 Vectors specifically is how retrieval latency holds up as knowledge base size grows. Object storage retrieval adds overhead compared to an in-memory index, and that gap may widen with larger datasets. Watching how that service matures over the next few product cycles will be informative for anyone considering it for production workloads.