3.1.3. Vector Databases on AWS (OpenSearch, Aurora, etc.)

First Principle: Vector databases are specialized databases designed to efficiently store and search on embeddings (numerical representations of data), making them the foundational technology for the "Retrieve" step in RAG architectures.

To implement RAG, you need a fast and scalable way to find relevant documents. This is where vector databases come in.

Key Concepts:

• Embeddings: As discussed before, embeddings are numerical vectors that represent the meaning of text, images, or other data.
• Vector Search (or Similarity Search): When a user asks a question, that question is also converted into an embedding vector. The vector database then performs a search to find the vectors in its index that are mathematically closest (most similar) to the question's vector. These are the most semantically relevant documents.
• Why it's necessary: Traditional keyword search would fail. A user might ask "How do I take time off?", but the HR policy document might use the phrase "requesting annual leave." A vector search understands the meaning and will correctly match these two phrases.

Vector Database Options on AWS:

• Amazon OpenSearch Service: Includes a k-Nearest Neighbor (k-NN) search capability, making it a powerful and scalable option for vector search.
• Amazon Aurora PostgreSQL with the pgvector extension: Allows you to add vector search capabilities to your existing relational database.
• Amazon RDS for PostgreSQL with the pgvector extension: Similar to Aurora, for RDS users.
• Amazon DocumentDB (with MongoDB compatibility): Supports vector search for document-oriented databases.
• Amazon Neptune: A graph database that also offers vector search capabilities.
• Amazon Bedrock Knowledge Base: A fully managed RAG capability that can manage the vector store for you, often using OpenSearch Serverless behind the scenes.

Scenario: A development team is building a RAG application. They have converted all their company documents into embedding vectors. They now need to choose a service to store these vectors and perform fast similarity searches.

Reflection Question: Why would they choose a service like Amazon OpenSearch Service with k-NN or Aurora with pgvector instead of a traditional SQL database with a LIKE clause for this task? What is the fundamental difference in how these databases perform the search?

💡 Tip: If your application needs to "find the most similar" items based on meaning (not just keywords), you need a vector database. It's the engine that powers modern RAG and recommendation systems. Choose Aurora with pgvector to add vector search to an existing relational database, or choose OpenSearch Service for a dedicated, highly scalable search solution.