Elegir la base de datos correcta para una app de IA no es lo mismo que elegirla para una app tradicional. Los patterns son distintos: mucha lectura por similaridad semántica, historial de conversación que cambia rápido, embeddings que no van bien en tablas relacionales, y latencia que importa porque el usuario está esperando una respuesta del LLM. En 2026, los AI Engineers y Data Engineers trabajan con tres bases de datos NoSQL de forma rutinaria: MongoDB, Redis y DynamoDB. Saber cuándo usar cada una te ahorra semanas de reingeniería.
No es que SQL haya muerto — sigue siendo indispensable para reportes, analytics y datos estructurados con relaciones complejas. El punto es que las apps con agentes tienen casos de uso específicos donde el modelo relacional te frena: almacenar el historial de conversación de decenas de miles de usuarios concurrentes, hacer búsqueda semántica sobre documentos internos, o mantener el estado de un agente que lleva horas corriendo. Ahí es donde entran estas tres.
MongoDB Atlas en 2026: la base de datos para apps conversacionales y búsqueda semántica
MongoDB sigue siendo la opción más natural para aplicaciones que manejan documentos semi-estructurados: el historial de conversación de un chatbot, los perfiles de usuario con preferencias variables, o los logs de un agente que incluyen tool calls, respuestas intermedias y metadatos de cada step. El modelo de documento encaja bien porque ese tipo de datos no tiene un schema fijo — cada conversación puede tener una estructura diferente y MongoDB lo maneja sin fricciones.
La novedad que cambió el juego en los últimos 12 meses es Atlas Vector Search: podés almacenar embeddings junto al documento en la misma base de datos, sin necesidad de un vector store separado como Pinecone o Weaviate. Para un sistema de RAG que ya usa MongoDB para los documentos, eso elimina una dependencia entera de la arquitectura. Los resultados de búsqueda semántica y el documento original están en el mismo lugar, con transacciones ACID incluidas y sin la latencia de red de una llamada a un servicio externo.
Cómo funciona en la práctica para RAG: en lugar de mantener dos sistemas separados — MongoDB para los documentos, Pinecone para los embeddings — Atlas Vector Search te permite almacenar y buscar vectores junto a los documentos en el mismo cluster. Las queries combinan filtros tradicionales con búsqueda semántica en una sola operación: "dame los 5 documentos más similares a esta query, pero solo del departamento de finanzas y publicados en los últimos 6 meses". Menos infraestructura, menos latencia de red, menos complejidad operativa.
Cuándo elegir MongoDB: historial de conversaciones, RAG con vector search integrado, perfiles de usuario con schema flexible, apps donde los datos cambian de estructura con el tiempo. Cuándo no elegirla directamente: si necesitás latencia sub-milisegundo para session state activo (usá Redis), o si hacés millones de escrituras por segundo sin necesidad de queries complejas (DynamoDB escala mejor con menor costo operativo).
Redis en 2026: la memoria a corto plazo de tus agentes
Redis tiene un rol específico en apps de IA que mucha gente subestima: es la memoria a corto plazo del sistema. No para almacenar todo el historial — para eso está MongoDB — sino para el estado activo de una sesión, el caché de respuestas del LLM, y el control de rate limiting de las llamadas a la API. En un agente de voz con latencia crítica, la diferencia entre Redis y una base de datos regular puede ser de 200ms a 2ms por operación.
Uno de los usos más interesantes es el semantic cache: en lugar de cachear por query exacta, Redis + embeddings cachean por similaridad semántica. Si alguien pregunta "¿cuáles son las ventajas de usar LangGraph?" y otro usuario ya preguntó "¿por qué conviene LangGraph en producción?", el sistema puede devolver la respuesta cacheada en lugar de llamar al LLM. Para apps con mucho tráfico, eso puede reducir los costos de API en un 30-40% sin impacto perceptible en la calidad.
Otro caso de uso que está creciendo en 2026: usar Redis como checkpoint store de LangGraph. Cuando el agente necesita persistir estado entre sesiones largas o entre workers del runtime distribuido, Redis funciona como el backend más rápido para el checkpointer. La latencia de lectura/escritura en Redis es de microsegundos, lo que importa cuando un agente procesa muchos steps y checkpointea en cada uno.
Cuándo elegir Redis: session state activo de agentes, semantic cache de LLMs, rate limiting de APIs, contadores en tiempo real, checkpoint store para LangGraph en producción. Cuándo no: como base de datos principal de documentos complejos, o para queries que necesitan filtros avanzados sobre muchos campos.
DynamoDB: cuando la escala es el único problema
DynamoDB es el extremo opuesto del espectro: sin gestión, sin capacity planning, escala automática hasta millones de operaciones por segundo con latencia predecible en un dígito de milisegundos. Para apps de agentes que manejan eventos en tiempo real — logs de pipelines, resultados de herramientas, callbacks de workflows — DynamoDB es la opción cuando la escala y la latencia predecible son más importantes que la flexibilidad del modelo de datos.
Lo que hay que saber antes de elegirla: DynamoDB te obliga a pensar bien los access patterns desde el diseño. No podés hacer queries ad-hoc fácilmente sin un scan completo (costoso). Si sabés exactamente cómo vas a leer los datos — por user_id, por session_id, por timestamp — es perfecta. Si necesitás flexibilidad para explorar los datos o hacer queries que no planeaste, MongoDB o PostgreSQL te van a ahorrar mucha frustración.
Cuándo usar cada una: la guía rápida
Antes de la decisión, una referencia rápida:
- ▸MongoDB Atlas: historial de conversaciones, RAG con vector search integrado, datos con schema flexible, apps conversacionales que necesitan queries complejas.
- ▸Redis: session state activo, semantic cache de LLMs, rate limiting de APIs, checkpoint store de LangGraph, contadores en tiempo real.
- ▸DynamoDB: eventos de alta velocidad, logs de agentes a escala masiva, tablas con access patterns fijos y millones de operaciones por segundo.
- ▸PostgreSQL + pgvector: si ya tenés Postgres en tu stack y el volumen de vectores no justifica un sistema dedicado, pgvector es una opción muy razonable en 2026 para proyectos medianos.
Lo que pocas guías te dicen sobre NoSQL en apps de IA
MongoDB no es automáticamente la mejor opción para todo lo que no encaja en SQL. El error más común que he visto es asumir que "necesito NoSQL" equivale a "necesito MongoDB". Si tu app hace principalmente lecturas puntuales por ID con latencia sub-milisegundo, DynamoDB gana por mucho. Si necesitás caché y session state de agentes, Redis es 10 veces más simple de operar y mantener. Elegir bien desde el principio te ahorra una migración dolorosa en 6 meses cuando la app crece.
Otro error frecuente: usar una base de datos NoSQL como si fuera SQL. NoSQL no es SQL sin tipos — es un modelo de datos diferente, con sus propias fortalezas y sus propias limitaciones. Las joins no existen en DynamoDB de forma nativa, los indices en MongoDB tienen un costo operativo, y Redis no es para datos persistentes que no podés permitirte perder. Cuando se entienden esas diferencias, la elección se vuelve mucho más clara.
Cómo aprenderlo todo junto
El curso NoSQL desde Cero de DataPath cubre MongoDB, Redis y los fundamentos de los modelos NoSQL con ejercicios prácticos — sin asumir que ya conocés el modelo relacional a fondo. Para conectar este conocimiento con el data engineering más amplio, la ruta Data Engineer incluye NoSQL dentro del stack completo: pipelines, bases de datos distribuidas, transformaciones y despliegue en cloud. Si querés el contexto de IA específicamente, la ruta AI Engineer cubre cómo estas bases de datos se integran con LLMs y agentes.
El stack de datos para apps con IA en 2026 no es una sola base de datos. Es MongoDB para documentos y búsqueda semántica, Redis para el estado activo y el caché, DynamoDB para la escala serverless. Aprender los tres y saber cuándo usar cada uno es una de las habilidades más prácticas que podés tener. El curso NoSQL desde Cero es el punto de partida más directo. La ruta Data Engineer te da todo el contexto de dónde encajan en una arquitectura moderna, y si querés conectarlo con el stack de agentes — LangGraph usa Redis como checkpoint store en producción — la ruta AI Agentic Engineer cubre exactamente ese puente.
