2.4.4. Configuring Scalable Vector Stores: OpenSearch, pgvector, and S3 Vectors
💡 First Principle: A vector store is chosen the same way as any storage in 2.1.2 — by access pattern, performance and cost — plus one new axis: what else must the query do besides nearest-neighbour search? Keyword relevance, aggregations, relational joins and cheap cold storage each point to a different engine.
All three in-scope options store embeddings and answer "find the k nearest vectors", but they optimize for different workloads:
| Option | Engine / index | Strengths | Watch for |
|---|---|---|---|
| Amazon OpenSearch Service (managed clusters) and OpenSearch Serverless vector search collections | knn_vector field in an index created with index.knn: true; managed clusters offer HNSW (Faiss or Lucene) and IVF (Faiss); Serverless Classic collections support only HNSW with Faiss, and NextGen collections choose the engine automatically | High query rates with low latency; hybrid search that combines vectors with full-text relevance, filtering, aggregations and geospatial queries; binary vectors | k-NN graphs live in memory: on managed clusters half of instance RAM goes to the JVM heap and k-NN graphs use up to 50% of the remainder by default |
| Amazon Aurora PostgreSQL or Amazon RDS for PostgreSQL with pgvector | vector(n) column; HNSW or IVFFlat index; operators for L2 (<->), cosine (<=>) and inner product (<#>) | Embeddings live beside relational data, transactions and SQL joins; reuse existing PostgreSQL skills | vector indexes support up to 2,000 dimensions (halfvec up to 4,000); Bedrock Knowledge Bases integrates with Aurora PostgreSQL (pgvector 0.5.0 or later, RDS Data API, Secrets Manager credentials) |
| Amazon S3 Vectors | Vector buckets containing vector indexes; cosine or Euclidean distance | Lowest-cost, elastic, durable storage with no infrastructure to provision; up to 2 billion vectors per index; strongly consistent writes | Sub-second latency for infrequent queries (as low as 100 ms for frequent ones) — suited to less frequent queries, not high-QPS search; float embeddings only in Bedrock Knowledge Bases |
Configuring to a specification. Most exam scenarios give you a spec — dimensions, distance metric, query volume, filtering needs — and ask for the matching configuration:
- Dimension must equal the embedding model's output (for example 1,024 for Titan Text V2 at its default). S3 Vectors accepts 1 to 4,096 dimensions per vector; the OpenSearch Service managed
knn_vectortype accepts up to 10,000; OpenSearch Serverless vector collections up to 16,000. - Distance metric should match how the embedding model was trained (cosine for normalized text embeddings is common; Bedrock recommends Euclidean for float embeddings in OpenSearch Serverless knowledge base indexes).
- Index algorithm: HNSW gives the best speed-recall trade-off at the cost of memory and slower builds; pgvector's IVFFlat builds faster with less memory but lower query performance and needs data in the table before the index is created.
- Metadata for filtering: S3 Vectors metadata is filterable by default; you can declare up to 10 non-filterable keys per index, with up to 2 KB filterable and 40 KB total metadata per vector (Bedrock Knowledge Bases limits custom metadata to 1 KB and 35 keys per vector on S3 Vectors). In Aurora, Bedrock writes metadata to a
custom_metadataJSONB column that needs a GIN index; enable HNSW iterative scans (pgvector 0.8.0 or later) so selective filters do not return fewer results than requested. - Access control: S3 Vectors uses its own IAM namespace (
s3vectors) and always has Block Public Access enabled.
Tiering across stores. The options combine. OpenSearch Service can use S3 Vectors as a lower-cost storage engine while keeping OpenSearch APIs, and an S3 vector index can be exported to OpenSearch Serverless when a workload later needs high QPS and low latency. A common pattern keeps a large archive of embeddings in S3 Vectors and a hot subset in OpenSearch.
⚠️ Exam Trap: "Lowest cost" and "millisecond latency at thousands of queries per second" pull in opposite directions. S3 Vectors is the answer when the stem stresses cost and infrequent or batch queries over very large vector sets; OpenSearch is the answer when it stresses sustained query throughput, hybrid lexical-plus-semantic ranking or aggregations. Also note that hierarchical chunking is not recommended with an S3 vector bucket in Bedrock Knowledge Bases, because parent-child relationships are stored as non-filterable metadata and large chunk sizes can exceed the metadata limits.
