AWSAWS Certified Generative AI Developer - Professional2026-101.4 Design and implement vector store solutions
Choose stores by retrieval and integration
Completed by the knowledge check
Learning objective
Compare OpenSearch Service and Aurora pgvector with Neptune Analytics GraphRAG and DocumentDB vector search; distinguish Knowledge Bases-supported backends from standalone stores.
Core idea
Choose a vector store on two axes: the retrieval behavior your application needs and the integration your ingestion and query path actually supports. A database that stores embeddings is not automatically a valid Amazon Bedrock Knowledge Bases backend. Conversely, a supported backend does not make every deployment of that service compatible.
A search-heavy application, a relational application, a relationship-heavy corpus, and a JSON document application can justify different stores. Evaluate those differences before optimizing index settings. The useful decision is who owns embedding generation, ingestion, filtering, and retrieval, not which service has the most features.
The complete Knowledge Bases supported vector-store list is Amazon OpenSearch Serverless, Amazon OpenSearch Service Managed Clusters, Amazon Neptune, Amazon Aurora (RDS), Pinecone, Redis Enterprise Cloud, MongoDB Atlas, and Amazon S3 Vectors. The Neptune integration discussed here uses Neptune Analytics.
This lesson compares storage boundaries. See 1.4.2 for the knowledge-base and data-source hierarchy, and 1.4.3 for an application-managed OpenSearch embedding pipeline.
How it works
OpenSearch Service: search-oriented retrieval
Amazon Bedrock Knowledge Bases lists both Amazon OpenSearch Serverless and Amazon OpenSearch Service managed clusters as supported vector stores. These are separate deployment options. In CreateKnowledgeBase, opensearchServerlessConfiguration identifies a collection and vector index, while opensearchManagedClusterConfiguration identifies a domain and vector index. Both map text, vectors, and metadata to fields.
OpenSearch fits a retrieval path that needs search-oriented indexing and semantic search. For a self-managed Knowledge Bases integration, AWS requires the Faiss engine rather than NMSLIB. The documented managed-cluster setup requires public access; a domain behind a virtual private cloud (VPC) is not supported by that integration. It requires engine version 2.13 or higher for the k-NN index, and 2.16 or higher for binary embeddings. Those are integration constraints, not a statement that application-managed OpenSearch cannot use a VPC.
Treat the collection or domain, index mapping, embedding dimensions, and access configuration as one compatibility contract. A working index in an application-managed pipeline does not prove that Knowledge Bases can ingest into it. Test the intended integration itself.
Aurora PostgreSQL: vectors beside relational data
Aurora PostgreSQL uses the pgvector extension to store and search embeddings. The Knowledge Bases integration requires pgvector 0.5.0 or higher, the RDS Data API, and credentials managed in AWS Secrets Manager. Its rdsConfiguration names the cluster, database, table, credentials secret, and field mappings.
The table separates the vector, chunk text, Bedrock-managed metadata, and optional custom metadata. customMetadataField can map a JSONB column used for application metadata; AWS documents a GIN index for that column. This gives a relational team a familiar database boundary, but it does not mean that arbitrary business tables become knowledge-base documents.
A custom retriever can combine vector search with relational queries over data in the same PostgreSQL instance. That capability belongs to the custom application query path. Do not assume the Knowledge Bases runtime automatically joins its chunk table to your customer or entitlement tables. If business metadata remains elsewhere, design the reconciliation explicitly; see 1.4.4.
Neptune Analytics: relationships plus vectors
Knowledge Bases GraphRAG integrates with Amazon Neptune Analytics for graph and vector storage. During ingestion, a graph-construction foundation model extracts entities, facts, and relationships from S3 documents. The embedding model provides vector representations. These are distinct model responsibilities.
The storage configuration uses neptuneAnalyticsConfiguration with a graphArn and field mappings. Existing graph vector dimensions must match the embedding dimensions. You can also use the documented quick-create flow rather than supplying existing graph infrastructure.
GraphRAG is a candidate when questions depend on relationships distributed across documents. For example, an investigation might need evidence connecting a supplier, its parent organization, and several incidents. A flat similarity result can retrieve relevant passages without establishing those connections. Graph construction adds another ingestion stage to evaluate; test extraction errors and the usefulness of relationship-based evidence rather than assuming a graph guarantees better answers.
DocumentDB: vectors inside JSON documents
Amazon DocumentDB supports vector search on version 5.0 and higher instance-based clusters. Its vector-search documentation describes HNSW and IVFFlat indexes and the $search stage with a vectorSearch operator. The indexable dimensionality limit is 2,000, while unindexed vectors can have up to 16,000 dimensions. Higher probes or efSearch settings trade search speed for recall in their respective index paths.
Match vector-query syntax and index options to the selected engine version and deployment type. Similar query names in related document databases do not establish interchangeable interfaces. Verify the actual service API rather than treating MongoDB ecosystem familiarity as a compatibility guarantee.
DocumentDB is absent from the Knowledge Bases supported vector-store list. MongoDB Atlas is on that list, but it is a different product. Choose DocumentDB for a custom retrieval path when its document model and existing application data justify it, and own embedding, indexing, retrieval, and prompt assembly in that path.
Key distinctions and trade-offs
The following comparison identifies the deciding boundary:
| Store | Retrieval fit | Knowledge Bases boundary |
|---|---|---|
| OpenSearch (Serverless or managed cluster) | Search-oriented semantic retrieval | Serverless and managed clusters are supported through different configurations and prerequisites. |
| Aurora PostgreSQL with pgvector | Relational data and vector similarity | Supported Aurora integration requires Data API, secret, and chunk-table mappings. |
| Neptune Analytics | Graph relationships with vector retrieval | Supported GraphRAG integration extracts relationships from S3 documents. |
| DocumentDB | JSON documents with vector similarity | Standalone/custom retrieval; do not substitute it for MongoDB Atlas support. |
Existing operational experience is a reason to shortlist a store, not evidence that it satisfies every requirement. Measure retrieval quality, filtered query behavior, ingestion recovery, and the deployment constraints that matter to your organization. Compare the whole path rather than isolated nearest-neighbor timings.
Architecture / decision scenario
A manufacturer has four assistants under review. Product support needs search over manuals; finance combines descriptions with relational account metadata; supplier investigations need connections across incident reports; a catalog assistant already manages JSON product documents in DocumentDB.
The team shortlists OpenSearch for support and Aurora pgvector for finance, checking the exact Knowledge Bases configurations before selecting either. It evaluates Neptune Analytics GraphRAG on supplier questions that require relationships across reports. For the catalog, it compares a custom DocumentDB retriever against exporting approved documents to a supported Knowledge Bases backend.
A requirement to reuse a VPC-only OpenSearch managed domain disqualifies that domain from the documented Knowledge Bases integration. It does not disqualify an application-managed search path. Likewise, a requirement to query DocumentDB directly means the team must own that path rather than labeling it a Knowledge Bases connector.
Common exam traps
- Treating every vector-capable AWS database as a Knowledge Bases backend.
- Confusing DocumentDB with the supported MongoDB Atlas integration.
- Assuming OpenSearch Serverless and managed-cluster prerequisites are identical.
- Treating Aurora vector storage as automatic retrieval from arbitrary relational tables.
- Confusing the GraphRAG graph-construction model with its embedding model.
- Selecting a database without checking embedding dimensions or deployment compatibility.
What to remember
- Separate retrieval capability from managed integration support.
- Compare the exact configuration, engine version, and network boundary.
- Use relational, graph, search, or document structures when the query requires them.
- A custom store means you own the missing ingestion and retrieval orchestration.
- Validate the complete path with representative questions and filters.
Knowledge check
A catalog team keeps its JSON product documents in Amazon DocumentDB and wants to query them directly with vector search for retrieval-augmented answers. Which plan is valid?
rdsConfigurationA team must reuse an existing OpenSearch Service managed domain that is reachable only inside a VPC. It runs engine version 2.15 and uses the Faiss engine. How can the team use this domain for retrieval?
Investigators ask which incidents link a supplier to its parent organization, and the evidence is spread across many reports. Flat similarity search returns relevant passages but not the connections. Which backend pattern is built for this retrieval need?
efSearch settingA finance team stores its Knowledge Bases chunk table in Aurora PostgreSQL. Customer entitlement tables sit in the same database, and the team expects retrieval to return only chunks a customer is entitled to. What must the team design?
pgvector extension applies row access to similarity searchA team creates a Knowledge Bases GraphRAG configuration against an existing Neptune Analytics graph whose vector dimension is 1,024. The chosen embedding model produces 1,536-dimension vectors. What should the team do?
References
- AWS, Turning data into a knowledge base
- 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, Create an Amazon Bedrock knowledge base with Amazon Neptune Analytics graphs
- AWS, Vector search for Amazon DocumentDB