3.1.1. Vector Database Options on AWS

💡 First Principle: No single vector database is optimal for all RAG use cases — the right choice depends on your existing infrastructure, query volume, metadata filtering needs, vector dimensionality, update frequency, and whether you need exact or approximate nearest-neighbor search.

AWS vector database comparison:

OpenSearch with the Neural plugin — the exam-critical configuration: When using OpenSearch for Bedrock Knowledge Bases integration, the Neural plugin enables k-NN vector search. The critical configuration decisions:

• k-NN algorithm: HNSW (Hierarchical Navigable Small World) for high recall; IVF for lower memory footprint at scale
• ef_construction / m parameters: Higher = better recall, slower indexing, more memory
• Sharding strategy: Shard count affects parallelism; too few shards → bottleneck; too many → overhead

# OpenSearch index mapping for vector search
index_mapping = {
    "settings": {
        "index": {
            "knn": True,
            "knn.algo_param.ef_search": 512  # Higher = better recall, slower queries
        }
    },
    "mappings": {
        "properties": {
            "embedding": {
                "type": "knn_vector",
                "dimension": 1024,  # Must match Titan Embeddings v2 output
                "method": {
                    "name": "hnsw",
                    "engine": "faiss",
                    "parameters": {"ef_construction": 512, "m": 16}
                }
            },
            "content": {"type": "text"},
            "document_id": {"type": "keyword"},
            "last_updated": {"type": "date"},
            "department": {"type": "keyword"}  # Enable filtered retrieval
        }
    }
}

⚠️ Exam Trap: The pgvector extension on Aurora PostgreSQL supports exact nearest-neighbor search by default, which guarantees 100% recall but scales poorly for large corpora (>1M vectors). For production-scale RAG, you must enable IVFFlat or HNSW indexes on pgvector to switch to approximate search — and ANN indexes require periodic re-building as data grows.

Beyond similarity — Amazon Neptune Analytics for GraphRAG: When answers depend on relationships between entities (which supplier ships which part, which policy supersedes which), pure vector similarity is not enough. Neptune Analytics combines graph traversal over entity relationships with vector similarity in a single engine — the basis of GraphRAG. Choose it when multi-hop relationship reasoning matters alongside semantic retrieval; OpenSearch and pgvector have no native graph traversal.

A default-and-switch heuristic: Default to OpenSearch Serverless for general-purpose production RAG (large-scale ANN, hybrid BM25 + semantic, metadata filtering). Switch only when a specific need overrides the default:

• Aurora PostgreSQL + pgvector — the data already lives in Aurora and you need vector results joined to relational columns inside one ACID transaction.
• Amazon MemoryDB for Redis — microsecond in-memory retrieval latency.
• Amazon Neptune Analytics — GraphRAG over entity relationships.

Reflection Question: Your team is building a RAG system for a legal research firm with 2 million case documents. They need to filter results by jurisdiction, case year, and practice area in addition to semantic similarity. They have an existing PostgreSQL expertise on the team. Which vector store would you recommend, and what index configuration consideration would you flag?