A vector store is not a RAG default. Retrieval economics belong in the architecture decision.

On 17 September, AWS published a selection framework for three vector stores behind Amazon Bedrock Knowledge Bases: Amazon OpenSearch Service, Aurora PostgreSQL with pgvector, and Amazon S3 Vectors. The comparison matters because a RAG stack can hide its most consequential infrastructure choice behind a single field labelled “vector store”.

The obvious reading is to pick the backend with the best benchmark. That is the wrong abstraction. Retrieval is a contract between latency, filtering, scale, operating model and cost, and each application weights those constraints differently.

The feature boundary comes before the benchmark

AWS documentation makes one boundary explicit: S3 Vectors supports semantic search but not hybrid search. It also limits custom metadata in Bedrock Knowledge Bases to 1 KB and 35 metadata keys per vector. Those are not implementation details if an application depends on lexical matching, rich filtering or large metadata envelopes.

OpenSearch and Aurora occupy different operating positions. OpenSearch is a search system with vector capabilities and filtering; Aurora puts vector retrieval beside relational data and SQL. S3 Vectors instead targets cost-optimised vector storage and retrieval at very large scale. A benchmark cannot erase those differences.

Choose the retrieval contract first. Benchmark the products that can actually satisfy it second.

Average latency is not the production metric

The application team should define the retrieval service level before choosing the store: percentile latency at expected concurrency, recall on a representative evaluation set, filter correctness, ingestion freshness, failure behaviour and cost per successful retrieval. Then test the candidate stores with the application's own chunk sizes, embedding dimensions, metadata and query mix.

This also changes migration planning. If hybrid search or relational joins are architectural requirements, moving later from a cheaper semantic-only store is not a storage migration; it can change ranking, filters and application behaviour. Conversely, paying for a richer search engine when the workload only needs infrequent semantic retrieval turns unused capability into recurring cost.

Make vector-store selection an evidence gate

For a new Bedrock Knowledge Bases deployment, record the required retrieval features and service levels in the architecture decision before provisioning. Run the same evaluation corpus against every viable backend, capture p95 latency, retrieval quality, ingestion time and unit cost, and retain the results with the decision.

Re-run that evaluation when corpus size, query volume, metadata design or retrieval strategy changes materially. The vector store is not plumbing beneath RAG. It is part of the model-serving path, and its constraints should be reviewed with the same evidence expected from any other production dependency.

Written by the Devence Lab research team.