Search⌘ K
AI Features
Home
Courses
Grokking the AWS Certified Machine Learning Engineer - Associate

Vector Stores for AI Applications

Explore the role of vector stores in AI applications and understand key configurations like dimensions, distance metrics, and index algorithms. This lesson helps you evaluate and choose between AWS vector stores such as OpenSearch Service, Aurora PostgreSQL with pgvector, and Amazon S3 Vectors. Gain insight into performance trade-offs, cost management, and integration with Bedrock Knowledge Bases to optimize retrieval at scale.

We'll cover the following...

Every generative AI application that retrieves context, whether a RAG assistant, a semantic search page, or an agent with long-term memory, stores embeddings somewhere. An embedding model turns each chunk of text or each image into a fixed-length array of numbers, and the vector store finds the arrays closest to a query vector in milliseconds. The previous lessons covered storage for training data. This lesson covers storage for retrieval, where the questions are different: how many dimensions, which distance metric, which index algorithm, how much memory, and how many queries per second.

The exam names three vector stores on AWS: Amazon OpenSearch Service (managed domains or OpenSearch Serverless), Amazon RDS with the pgvector extension (Amazon Aurora PostgreSQL-Compatible Edition or Amazon RDS for PostgreSQL), and Amazon S3 Vectors. All three work with Amazon Bedrock Knowledge Bases, which the RAG lesson in Chapter 8 introduces. A correct configuration is one where the index matches the embedding model, the store scales to the expected vector count and query rate, and the storage bill matches how often the vectors are actually queried.

The diagram below shows where the vector store sits between the embedding model and the application.

Where the vector store sits in a retrieval workload
Where the vector store sits in a retrieval workload

Settings every vector index needs

Whatever the store, four settings define a vector index, and most of them can't be changed without rebuilding it:

  • Dimension: The length of each vector. It must equal the output of the embedding model. Amazon Titan Text Embeddings V2 produces 1,024, 512, or 256 dimensions, while Titan G1 Embeddings - Text produces 1,536. A mismatch makes every write fail.

  • Distance metric: How closeness is measured: Euclidean (L2), cosine, or inner (dot) product. Use the metric the embedding model was designed for, and query with the same metric that the index was built with.

  • Index algorithm: Exact search compares the query to every vector, which is accurate but slow at scale. Approximate nearest neighbor (ANN) algorithms trade a little recall for speed. HNSW (Hierarchical Navigable Small World) builds a graph and gives the best latency and recall but uses the most memory. IVF (inverted file) clusters vectors into lists and searches only the nearest lists, which uses less memory but needs training data before it is built.

  • Metadata: ...