2.6 Vector Database Selection: OpenSearch Serverless vs Aurora pgvector vs Managed Stores
Key Takeaways
- Amazon OpenSearch Serverless (Vector Engine) is the default fully managed, serverless vector store for Bedrock Knowledge Bases, auto-scaling compute via OpenSearch Compute Units (OCUs) without cluster administration.
- Amazon Aurora PostgreSQL with the pgvector extension enables hybrid workloads where vector similarity search is combined with ACID-compliant relational SQL queries, table joins, and row-level security.
- The HNSW index algorithm prioritizes high query recall and low search latency at the expense of higher memory usage and slower index build times, whereas IVFFlat provides faster indexing and lower RAM overhead at the expense of lower recall and required retraining.
- Third-party managed vector databases supported by Bedrock Knowledge Bases include Pinecone, MongoDB Atlas, and Redis Enterprise Cloud, connecting securely via AWS Secrets Manager.
- Multi-tenant vector architectures must choose between metadata filtering (shared index with tenant ID filtering) for cost-efficiency and index/table isolation for strict regulatory data partitioning.
2.6 Vector Database Selection: OpenSearch Serverless vs Aurora pgvector vs Managed Stores
Amazon Bedrock Knowledge Bases separates retrieval orchestration from vector storage. The correct store is therefore not simply the one with the highest advertised benchmark. It is the supported backend that satisfies the workload's retrieval modes, metadata filters, scale, availability, security boundary, operational model, and cost constraints in the required Region.
Current supported storage types
The Bedrock StorageConfiguration API currently lists eight vector-store types: OpenSearch Serverless, Pinecone, Redis Enterprise Cloud, Amazon RDS, MongoDB Atlas, Neptune Analytics, OpenSearch managed clusters, and Amazon S3 Vectors. In the RDS path, Bedrock Knowledge Bases commonly uses Amazon Aurora PostgreSQL-Compatible Edition with pgvector. Support and feature combinations can differ by Region, data type, and creation workflow, so confirm the current table for the selected architecture.
| Store | Strong fit | Important tradeoff to evaluate |
|---|---|---|
| OpenSearch Serverless | Managed semantic and hybrid search with AWS-native policies and automatic capacity management | Collection generation, OCU limits, cold-start behavior, network policy, and maximum-cost controls |
| OpenSearch managed cluster | Teams that need cluster-level OpenSearch control or already operate compatible domains | Instance, shard, patching, and scaling responsibility |
| Aurora PostgreSQL with pgvector | Vector retrieval combined with relational joins, transactions, and row-level security | Database sizing, connection management, index maintenance, and SQL tuning |
| Amazon S3 Vectors | Durable, cost-oriented vector storage for supported retrieval workloads | Verify query features, latency needs, metadata support, and Region availability |
| Neptune Analytics | Graph-aware retrieval where relationships are central to the question | Graph modeling and workload-specific operational cost |
| Pinecone | An existing Pinecone platform or a managed multi-cloud vector strategy | External service credentials, network path, tenancy, and vendor operations |
| MongoDB Atlas | Documents and vectors managed with an existing Atlas document model | External service configuration, network path, and index feature compatibility |
| Redis Enterprise Cloud | Workloads already using Redis vector capabilities and requiring its access patterns | Memory-oriented economics, persistence design, and external service management |
This list describes supported storage configuration types, not feature equivalence. For example, a backend can support vector retrieval while differing on hybrid search, filtering operators, binary vectors, multimodal data, or managed creation. Test the exact combination instead of transferring a capability from one store to all stores.
OpenSearch Serverless capacity is generation dependent
OpenSearch Serverless measures compute in OpenSearch Compute Units. Current next-generation collection groups can set independent minimum and maximum indexing and search capacity, and a minimum of zero enables scale to zero. Classic collections follow different rules. A next-generation group that has been idle can add first-request latency while workers resume, so zero idle cost and consistently warm latency are different objectives.
Set maximum capacity as a cost boundary and monitor indexing and search OCU use. Do not memorize the older four-OCU floor as a universal rule. Also account for collection grouping, encryption keys, and workload isolation when estimating shared capacity. The exam-worthy reasoning is to identify the collection generation and requirements before calculating cost.
Aurora pgvector decision pattern
Aurora is attractive when vector similarity must be combined with authoritative relational predicates. A bank might retrieve semantically relevant loan clauses while joining customer, region, and active-contract tables in one controlled database path. PostgreSQL row-level security can reinforce tenant rules, although the application must still set and test the correct database identity.
Index choice is empirical. HNSW often favors query recall and latency at the cost of memory and build work; IVFFlat exposes different build, probe, and recall tradeoffs. Neither has a universal recall percentage. Benchmark with the actual corpus, update pattern, filters, top-k, and concurrency. Migration requires re-embedding when the embedding contract changes, dual-read or replay controls, and a measured cutover.
Security and lifecycle checks
For every candidate store, map the complete path: Bedrock service role, secrets or database credentials, KMS keys, network policy, data-access policy, tenant filter, backup or durability behavior, deletion workflow, and audit evidence. A vector-store filter is not the sole authorization boundary. Resolve identity in trusted application code, constrain queries server-side, and run negative cross-tenant tests.
Estimate cost with representative vector count, dimension and type, metadata volume, index build traffic, query rate, idle periods, replicas or availability settings, and data transfer. Benchmark quality and tail latency under filtered queries, not only unfiltered nearest-neighbor search. Select the simplest backend that meets the verified contract, then record the support and pricing assumptions so a future service change triggers review.
A healthcare analytics company requires a vector database for an Amazon Bedrock Knowledge Base. The solution must execute vector similarity searches over patient clinical notes while simultaneously performing relational joins against an existing SQL schema containing patient consent records and HIPAA access control tables. Which vector store best satisfies these architectural requirements?