为亚马逊Bedrock知识库选择载体商店

When building a Retrieval Augmented Generation (RAG) solution with Amazon Bedrock Knowledge Bases, selecting the right vector store impacts performance and cost. Amazon Bedrock Knowledge Bases offers a fully managed option and a customer-managed option where you choose your own vector store. This post focuses on the customer-managed path, comparing the three supported backends: Amazon OpenSearch Service, Amazon Aurora PostgreSQL with pgvector, and Amazon S3 Vectors, a capability of Amazon Simple Storage Service (Amazon S3), across distinct RAG use cases.

For broader guidance across all AWS vector solutions, see AWS vector solutions: Build agentic AI where your data lives. For the role of vector datastores in generative AI applications, see The role of vector datastores in generative AI applications. For prescriptive guidance on vector databases for RAG, see Choosing an AWS vector database for RAG use cases.

How vector databases fit into RAG solutions

A RAG architecture combines the capabilities of large language models (LLMs) with information retrieval systems to generate more accurate, up-to-date, and contextually relevant responses. It is based on the mathematical concept of a vector, where the text is translated into vectors that align to the meaning of the text. A search performed on vectors will find results that have similar meaning to the question, which is more effective at capturing semantic similarity than keyword matching.

When a user submits a query, it is converted into a vector embedding using an embedding model. The vector database, where document content has been pre-processed, chunked, and stored as vector embeddings, performs a similarity search to find the chunks whose embeddings are most similar to the query. Typically, the system retrieves the top n chunks (for example, the top five most similar) to enrich the original query. These retrieved chunks are provided to the LLM as additional context so it can generate a more informed, accurate response.

The vector database serves as the key bridge between raw information and contextual understanding. It transforms unstructured data into a searchable, semantically meaningful knowledge space that helps large language models deliver more precise and relevant responses. Vector databases achieve this by storing embedding vectors in an efficient data structure called a vector index, which supports rapid, high-dimensional semantic searches and near-instantaneous retrieval of semantically similar information.

Vector store backends for Amazon Bedrock Knowledge Bases

Amazon Bedrock Knowledge Bases with a customer-managed (unmanaged) configuration supports three vector store backends. For the full AWS vector portfolio covering six services, see AWS vector solutions: Build agentic AI where your data lives.

Amazon OpenSearch Service provides high-speed results from data held in memory. It supports high-dimensional vector embeddings with both managed cluster and serverless deployment options, and features including k-NN search and hybrid search combining lexical and vector approaches. Amazon Bedrock Knowledge Bases supports both Amazon OpenSearch Managed Clusters and Amazon OpenSearch Serverless as vector store backends.

Amazon Aurora PostgreSQL with pgvector combines the high-performance relational database capabilities of Amazon Aurora with pgvector’s vector similarity search functionality. It supports multiple indexing methods (IVFFlat and HNSW), various distance metrics (L2, cosine, inner product), and can handle vectors up to 2,000 dimensions in single precision.

Amazon S3 Vectors is the AWS cloud object storage service with native vector support, designed for cost-effective storage and querying of vector embeddings at scale. It provides sub-second query performance for similarity searches while reducing vector storage costs by up to 90 percent compared to traditional vector databases.

To understand how these options perform in practice, let’s examine three distinct RAG use cases, each with different latency, cost, and search requirements, and see which vector database is the best fit for each.

Use case 1: Product catalog search

Ecommerce platforms face the challenge of helping customers find exactly what they’re looking for among thousands of products. An effective product search tool must understand natural language queries and scale to handle thousands of concurrent queries during peak shopping periods while maintaining low latency.

Why Amazon OpenSearch is the best fit for this use case

Amazon OpenSearch Serverless is well suited for product catalog search because it supports combining semantic understanding with traditional keyword matching through hybrid search capabilities. When dealing with large product catalogs, performance matters. Amazon OpenSearch Serverless handles vector search with query latency in the low milliseconds range.

What makes it particularly valuable for ecommerce is the built-in support for complex filtering and aggregations that power faceted navigation (think filtering by price, brand, or color). You can also choose from multiple distance metrics like cosine similarity or Euclidean distance to fine-tune how product similarity is calculated based on your specific needs.

Amazon OpenSearch Serverless Classic collections offer several optimization options to balance cost and search quality, as detailed in the following section.

Note: Amazon Bedrock Knowledge Bases supports both Amazon OpenSearch Serverless and Managed Clusters. The following benchmarks were run on Serverless Classic collections. Amazon OpenSearch Serverless NextGen collections (generally available May 2026) aren’t yet compatible with the Amazon Bedrock Knowledge Bases Retrieve API. NextGen simplifies index creation by removing the engine and mode parameters from index mappings, defaults to 32× compression with GPU-accelerated index builds, and supports scale-to-zero. The benchmarks in this post use Classic collections, where engine, mode, and HNSW parameters are configured explicitly. Managed Clusters offer additional tuning options (auto-optimize, GPU-accelerated indexing, configurable instance sizing) that may yield different results.

Performance analysis and optimizations for Amazon OpenSearch serverless vector search

Amazon OpenSearch is highly configurable and provides several configuration options. Be careful when selecting these options because they can significantly affect the performance of the vector index. We consider some of these options targeted at optimizing cost and database size and quantitatively demonstrate their impact on vector index performance.

Some of the common optimization options are:

1. Size of vector embeddings: A larger vector can generally contain more semantic information about the embedded text. However, it also leads to higher memory consumption, which increases vector index size and cost. Modern embedding models like Amazon Titan Text Embedding v2 offer the ability to embed text in vectors of different sizes (1024, 512, or 256 for Amazon Titan). It is useful to benchmark performance of embeddings of different size to quantitatively measure impact of performance and cost on a particular use case. For model availability by AWS Region, refer to Supported models by AWS Region in Amazon Bedrock.
2. Data type of embeddings: We can also reduce vector index size (and thus cost) by storing embeddings in lower precision data types, such as binary embeddings. This can significantly reduce the size of the vector index.
3. Disk optimized storage: Amazon OpenSearch Serverless Classic collections offer disk-based vector search (on_disk mode) that applies 32× binary quantization internally while rescoring against full-precision vectors from disk. This preserves quality while reducing in-memory footprint, at the cost of higher latency. Note that on_disk requires float data type and can’t be combined with binary embeddings.

Depending on the indexing algorithm used, users may also configure HNSW parameters (ef_construction, m) to tune the trade-off between index build time, memory usage, and search accuracy (for practical guidance, see A practical guide to selecting HNSW hyperparameters). Additionally, Faiss 16-bit scalar quantization is available on Classic collections to reduce memory usage. Choosing embedding dimension and data type requires evaluating against your own relevance data, as these change the embedding space itself. After selected, the auto-optimize feature can remove the remaining HNSW and quantization tuning in under an hour, by evaluating index configurations against recall and latency thresholds (available for both Amazon OpenSearch Serverless and Managed Clusters with Faiss engine).

Dataset

We use the “Shopping Queries Data Set” (ESCI), a large dataset of difficult search queries provided by Amazon. The dataset contains 1,215,851 unique US products (title, description, bullets, and brand; approximately 1,140 characters median) and 97,345 judged queries. For each query, the dataset provides graded relevance labels: Exact (3), Substitute (2), Complement (1), and Irrelevant (0). An example query and a relevant and irrelevant product are shown in the following examples.

Query:

self-seal envelopes without window

Relevant product title:

BAZIC Security Self Seal Envelope 4 1/8" x 9 1/2" #10, No Window Tint Pattern Mailing Envelopes, Peel & Seal, Office Checks Invoices (30/Pack), 1-Pack

Irrelevant product title:

ValBox 200 Count #8 Double Window Envelopes 3 5/8" x 8 11/16" Flip and Seal Double Window Security Check Envelopes- Security Tint Pattern Designed for Home Office Secure Mailing

We sample 5,000 queries (approximately 19 judged products per query, approximately 17 relevant) and index all 1,215,851 product descriptions for benchmarking. We measure retrieval quality (NDCG@10), latency (p50/p95/p99 at concurrency 1 and 10), and index size (ANN in-memory footprint).

Vector index construction

We test all combinations of embedding dimension (1024, 512, 256) and data type (float, binary), totaling six configurations, plus 1024-float in on_disk mode at the default compression_level: 32x, compared against the 1024-float in-memory baseline (seven configurations total). All indexes use FAISS with HNSW (ef_construction=128, m=24), l2 distance for float embeddings and hamming for binary. Note that on_disk mode requires data_type: float and applies its own binary quantization internally at 32×, rescoring against full-precision vectors read from disk. So “1024-dim binary on_disk” is not a valid index configuration. Each index is created alone in the collection, ingested with all 1.22M documents, warmed until latency stabilizes, measured, then deleted with a 15-minute cool down before the next configuration.

Configuration	Embedding size	Embedding type
In memory	1024	float (baseline)
In memory	512	float
In memory	256	float
In memory	1024	binary
In memory	512	binary
In memory	256	binary
On disk (32×)	1024	float

Evaluation methodology

For each configuration, we create a vector index in Amazon OpenSearch Serverless (Classic collection), ingest all 1,215,851 products, wait for merges to settle, then run an adaptive warm-up until latency stabilizes before measuring. We measure 1,000 queries × 3 repetitions at concurrency 1 and concurrency 10. Configuration order was interleaved so data type and dimension are decorrelated from time. The main benchmark (Table 1) uses semantic search (k-NN only). We separately evaluate hybrid search (semantic + keyword with BM25) in Table 2. We evaluate:

1. Retrieval latency: Latency is measured as the time taken to retrieve relevant matches from the vector index as reported by the Amazon OpenSearch results. This doesn’t include the time to convert text to embeddings.
2. Retrieval performance: We use the Normalized Discounted Cumulative Gain (NDCG) metric to score the retrievals for each query. This metric measures the quality of ranked retrieval results by considering both the relevance of retrieved documents and their position in the ranking. Higher-ranked relevant documents contribute more to the overall score than those ranked lower. The score is normalized against the ideal possible ranking to fall between 0–1, which is especially important in product search, where users are more likely to look at top results.
3. Index size: We report the ANN (Approximate Nearest Neighbor) index size, which is the in-memory structure that drives search compute cost and determines capacity requirements. This differs from total store size, which includes the _source JSON copy of each document and varies with document text volume.

Results

Table 1: Semantic search (k-NN only) performance across seven Amazon OpenSearch Serverless configurations (1,215,851 indexed vectors, 5,000 queries, k=10). Latency is server-side at concurrency 1 unless noted. Deltas are paired bootstrap against the 1024-float in-memory baseline. See Table 2 for hybrid search results.

1. Reducing dimensions doesn’t always reduce quality. On this dataset, 512-float was statistically indistinguishable from the 1024-float baseline (NDCG 0.3628 vs 0.3627, p = 0.87) at half the index size (2.79 vs 5.34 GiB) and lower latency (25 vs 31 ms p50). Dropping to 256 dimensions showed a measurable 4.4 percent quality loss. The gap between “lossless” and “lossy” dimension reduction will depend on the embedding model and dataset.
2. Binarization offers large index size reductions, but the quality cost depends on the number of dimensions. At 1024 dimensions, binary embeddings reduced index size by 13.4× (0.40 vs 5.34 GiB) with a 5.2 percent NDCG loss and comparable latency (22 vs 31 ms p50). At 256 dimensions the quality cost rose to 28.3 percent while the incremental size saving was much smaller (5.0×). On this dataset, the trend was clear: the binary penalty grows as dimensions shrink, suggesting that reducing precision at higher dimensions is more efficient than reducing both precision and dimensions.
3. Disk mode (on_disk 32×) preserves quality at the cost of latency. At 1024 dimensions, disk mode achieved NDCG 0.3610 (−0.5 percent vs baseline) with the same 0.40 GiB index size as 1024-binary, but at approximately 3× higher latency (99 ms p50 vs 31 ms in-memory). Both 1024-binary and on_disk reduce the index by 13.4×, but disk mode retained significantly more quality (−0.5 percent vs −5.2 percent). The approximately 3× latency ratio was consistent across p50, p95, and p99. At small corpus sizes this penalty may not appear because the index fits in page cache. It emerges at production scale.

Configuration	NDCG@10	Δ vs baseline	p50 (ms)	p95 (ms)	p99 (ms)	Index size (ANN)	p50 @ conc 10
1024 float	0.3627	baseline	31	44	52	5.34 GiB	161 ms
512 float	0.3628	+0.0002	25	37	62	2.79 GiB	149 ms
256 float	0.3468	−4.4%	22	35	47	1.51 GiB	85 ms
1024 binary	0.3438	−5.2%	22	37	55	0.40 GiB	70 ms
512 binary	0.3200	−11.8%	19	30	47	0.32 GiB	57 ms
256 binary