This is where everything comes together.
👉 In case you missed it:
- Part 1 → Embeddings, Dimensions, and Similarity Search
- Part 2 → Search Patterns, Filtering, and Chunking
By now, you understand the fundamentals and how retrieval works. The real question is:
Summary Comparison
| Service | Model | Strength | Scaling | Bedrock KB |
|---|---|---|---|---|
| OpenSearch Serverless | Distributed | Full-text + semantic search | Automatic (OCU) | Yes |
| Aurora pgvector | Relational | SQL + vector hybrid queries | Serverless v2 | Yes |
| S3 Vectors | Object storage | Massive scale, lowest cost | Fully serverless | Yes |
| MemoryDB | In-memory | Ultra-low latency | Cluster-based | No |
| Valkey (ElastiCache) | In-memory | Semantic caching | Cluster-based | No |
| Neptune Analytics | Graph | Relationships + vectors | Automatic | Yes |
| DocumentDB | Document | JSON + vector workloads | Instance-based | Yes |
| Kendra | Managed | Enterprise search | Fully managed | N/A |
Decision Matrix
| Scenario | Recommended | Alternative |
|---|---|---|
| General-purpose RAG | OpenSearch Serverless | Aurora pgvector |
| Existing PostgreSQL app | Aurora pgvector | DocumentDB |
| Ultra-low latency (real-time) | MemoryDB | Valkey |
| Reduce LLM cost (caching) | Valkey | MemoryDB |
| Knowledge graph + vectors | Neptune | OpenSearch |
| Massive scale (billions) | S3 Vectors | OpenSearch |
| Enterprise search (managed) | Kendra | Bedrock KB + S3 |
| Agent memory (short-term) | Valkey / MemoryDB | S3 Vectors |
Cost Reality (2026)
| Service | Model | Key Driver |
|---|---|---|
| S3 Vectors | Storage + query | Cheapest at scale |
| Aurora pgvector | Instance + storage | Cheaper if shared DB |
| OpenSearch Serverless | OCU hours | Minimum baseline cost |
| DocumentDB | Instance + I/O | I/O adds up |
| MemoryDB / Valkey | In-memory | RAM is expensive |
| Kendra | Flat fee | Enterprise pricing |
Graviton5 has reduced compute costs by ~20%, but memory-heavy systems still cost the most.
When NOT to Use a Vector Database
Before building anything, check this:
- Small dataset (<10K) → use in-memory search
- Exact match queries → use SQL or search index
- Structured filtering only → use a database
- Static FAQ → use a lookup table
- Real-time transactions → use relational/NoSQL DB
- Near-zero budget → use FAISS + S3
That’s a wrap on the series. If you’re building with RAG or semantic search on AWS, you now have both the conceptual foundation and practical guidance to choose the right architecture.