Configure stores for the retrieval contract

Learning objective

Configure OpenSearch vector search, Aurora pgvector, and Knowledge Bases vector-store integrations.

Core idea

A working vector database is not automatically a working Amazon Bedrock Knowledge Bases integration. The integration needs a supported store configuration, compatible vector representation, fields for text and metadata, and permissions that let the knowledge-base service role use the store. Configure the complete contract before ingestion.

This lesson covers self-managed knowledge bases, where you supply storageConfiguration. AWS’s CreateKnowledgeBase documentation also describes managed knowledge bases that require no vector-store configuration. Keep that distinction explicit: selecting a managed mode does not mean that the OpenSearch or Aurora setup described here silently happens in your own database.

How it works

Configure OpenSearch’s vector interface

For OpenSearch k-nearest-neighbor search, create an index with index.knn: true and a field of type knn_vector. Set the field’s dimension to match the selected embedding output. Preserve fields for the source text and metadata rather than storing only a vector with no recoverable evidence.

A direct search uses a knn query containing the query vector and k, with a top-level size. AWS warns that omitting size can return k results per shard and segment rather than the intended number for the whole query. Mixing the query with other clauses, such as post_filter, can produce fewer than k results. Assess the final filtered evidence set instead of assuming that k is a guaranteed count.

For a Knowledge Bases OpenSearch Serverless integration, create a vector search collection and use the Faiss engine for its vector field. Record the collection ARN and vector index name. The Bedrock setup documentation requires matching dimensions and maps the vector, raw text, and Bedrock-managed metadata fields into the knowledge-base configuration.

OpenSearch Serverless and OpenSearch managed clusters are distinct deployment choices. The Bedrock setup page documents private Serverless collections using VPC access and an endpoint. In contrast, its managed-cluster integration requires a public-access domain and states that domains behind a VPC are unsupported for that integration. Do not generalize the latter restriction to every custom OpenSearch application or to Serverless collections.

For the managed-cluster Knowledge Bases path, AWS specifies Faiss and states that nmslib is unsupported. It documents OpenSearch engine version 2.13 or higher for the k-NN index, and 2.16 or later when using binary vector embeddings. The example mapping uses HNSW with space_type: l2 for float embeddings or hamming with data_type: binary for binary embeddings. These are integration constraints, not a catalog of every engine that standalone OpenSearch can use.

Prepare Aurora PostgreSQL with pgvector

The Aurora Knowledge Bases integration requires an Aurora PostgreSQL cluster, RDS Data API, and a database user managed through AWS Secrets Manager. AWS documents pgvector version 0.5.0 or higher for HNSW support. Enable the extension with CREATE EXTENSION IF NOT EXISTS vector in the target database, and confirm the installed version rather than assuming the database includes the required extension.

The integration table needs a primary key, embedding vector, text chunks, and Bedrock-managed metadata. AWS’s example uses id uuid PRIMARY KEY, embedding vector(n), chunks text, and metadata json. Replace n with the embedding dimension. An optional custom_metadata jsonb column stores custom source attributes; without it, prepare individual columns for those attributes before ingestion.

Create an HNSW vector index with vector_cosine_ops, a GIN text index using to_tsvector('simple', chunks), and a GIN index on custom_metadata when that column is present. These indexes serve different query paths: vector similarity, raw-text search, and custom-metadata filtering. A vector index alone does not replace the text and metadata preparation required by the integration.

Selective filters need particular attention. AWS recommends HNSW iterative scans for metadata filtering with pgvector 0.8.0 or later. Its documented settings include hnsw.iterative_scan = 'relaxed_order' and hnsw.max_scan_tuples = 20000. Without iterative scans, filtering after the HNSW scan can leave fewer results than expected. The settings take effect for new sessions; existing RDS Data API pool sessions need time to recycle.

The Aurora cluster must be in the same AWS account as the knowledge base. AWS also states that the table field choices must exist before knowledge-base creation and cannot be updated afterward. Plan those fields as an integration interface, not as a schema you can rename freely after ingestion.

Bind the store through Knowledge Bases

CreateKnowledgeBase identifies the embedding model through knowledgeBaseConfiguration.vectorKnowledgeBaseConfiguration.embeddingModelArn. Its embeddingModelConfiguration.bedrockEmbeddingModelConfiguration carries representation settings such as dimensions and embeddingDataType. embeddingDataType accepts FLOAT32 (the default) or BINARY, and the embedding model must support the type you specify. Set those values consistently with the store; see 1.5.4 for batch and query compatibility.

The storageConfiguration.type discriminator selects OPENSEARCH_SERVERLESS, PINECONE, REDIS_ENTERPRISE_CLOUD, RDS, MONGO_DB_ATLAS, NEPTUNE_ANALYTICS, OPENSEARCH_MANAGED_CLUSTER, or S3_VECTORS. Select the matching configuration object rather than supplying a store object with an unrelated discriminator.

For Serverless, storageConfiguration.opensearchServerlessConfiguration contains collectionArn, vectorIndexName, and fieldMapping with vectorField, textField, and metadataField. Those fields refer to the actual index fields, not to arbitrary application labels.

For a managed OpenSearch cluster, storageConfiguration.opensearchManagedClusterConfiguration contains domainArn, domainEndpoint, vectorIndexName, and fieldMapping with vectorField, textField, and metadataField.

For Aurora, storageConfiguration.rdsConfiguration contains resourceArn, databaseName, tableName, and credentialsSecretArn. Its fieldMapping includes primaryKeyField, vectorField, textField, metadataField, and optionally customMetadataField. Give the knowledge-base role the documented resource permissions and verify that its configuration points to the intended secret and database.

AWS documents additional vector-store integrations, but compatibility varies with embedding dimensions and data type. Its setup page states that binary vectors are supported only by OpenSearch Serverless and OpenSearch managed clusters. Do not choose binary output and then assume the same representation can be stored through the Aurora integration.

Key distinctions and trade-offs

Use the deployment’s requirements to decide between these paths:

Existing database ownership can make Aurora operationally attractive, but shared capacity still needs testing. A vector-search collection can fit search-focused operations, but its integration does not remove access-policy or schema requirements. Compare query latency, ingestion behavior, filtering, and recovery under your expected load.

Architecture / decision scenario

A service team evaluates three deployment policies. Its private search workload can use an OpenSearch Serverless collection with VPC access. An existing managed OpenSearch domain sits behind a VPC, so the documented Knowledge Bases managed-cluster integration does not satisfy that policy. The team does not weaken the policy merely to reuse the domain.

A second team already operates Aurora PostgreSQL and needs structured metadata filters. It enables Data API, checks pgvector, prepares a dimension-matched table, and creates vector, text, and metadata indexes. Its filter tests return too few passages, so it evaluates the documented iterative-scan settings with a qualifying extension version.

Both teams validate actual fieldMapping values before ingestion and use the same embedding contract for documents and queries. They choose the deployment from supported integration behavior and measured workload results, rather than treating all vector stores as interchangeable containers.

Common exam traps

• Treating a database’s generic vector support as proof of Knowledge Bases compatibility.
• Omitting OpenSearch size and expecting k to bound the whole response.
• Applying managed-cluster VPC restrictions to OpenSearch Serverless.
• Preparing only Aurora’s vector index while ignoring text and metadata indexes.
• Choosing binary embeddings for the Aurora integration.
• Renaming mapped Aurora fields after knowledge-base creation.

What to remember

• Match model representation, vector schema, and field mappings.
• Scope network and engine constraints to the specific integration.
• Aurora requires Data API, pgvector, a secret, and the appropriate SQL indexes.
• Metadata filters can change the number of useful returned neighbors.
• Verify the complete integration before releasing ingestion or retrieval.

Knowledge check

References

• AWS, Prerequisites for using a vector store you created for a knowledge base

• AWS, Using Aurora PostgreSQL as a knowledge base for Amazon Bedrock

• AWS, k-Nearest Neighbor (k-NN) search in Amazon OpenSearch Service

• AWS, CreateKnowledgeBase

• AWS, StorageConfiguration