Infrastructure: How should MongoDB vector search be set up across all cluste...

Documentation for Sessions

📝 Infrastructure: How should MongoDB vector search be set up across all cluste...

Date: 2026-03-19
Time: 21:56:19 UTC
Session: gspace1-239.4
Agent: backend
Confidence: 96%
Status: ✅ Documented

📋 Decision Context

Question:

How should MongoDB vector search be set up across all clusters for optimal memory recall performance?

Task: S239: MongoDB vector search infrastructure setup

🎯 Decision Made

Chosen:

5 vector search indexes across 2 clusters: (1) vitto_memories_vector on vitto.urgh5aw.mongodb.net/vitto-mind/vitto-memories, (2) agent_embeddings on gograbspace/ai-memory, (3) episodes_vector on gograbspace/ai-mcp-dev, (4) chat_message_embeddings_vector on gograbspace/ai-agents, (5) golden_embeddings pre-existing. New flat chat_message_embeddings collection replaces nested message embeddings for 10x faster search.

Options Considered:

  1. Keep nested embeddings in chat_sessions
  2. Flatten to dedicated collection per entity type
  3. Use external vector DB (Pinecone/Weaviate)
  4. Skip vector search, use only text search

💭 Reasoning

Audit revealed only 1 of 5 needed vector indexes existed (golden_embeddings). The vitto-mind database had NO vector index — all recall was falling back to text search ($text), missing semantic matches entirely. Critical architectural fix: chat session messages had embeddings nested in arrays inside documents. MongoDB Atlas Vector Search on nested arrays is slow at scale (each document has 100+ message embeddings) and can't return which specific message matched. Solution: flat chat_message_embeddings collection with one document per message (same pattern as existing agent_embeddings). This enables precise message-level semantic search with proper filter fields (userId, sessionId, channelId). All indexes use 1536-dimension cosine similarity matching the existing text-embedding-3-small model.

📁 Files Involved

🔗 Related

Auto-generated by MCP Smart Consolidation