La latencia por debajo del milisegundo ya no es un lujo reservado a las mesas de trading. Los pipelines de inferencia de IA, los motores de recomendación en vivo y los dashboards orientados a eventos han convertido ese requisito en una necesidad habitual en la planificación de infraestructura. Cuando tu carga de trabajo llega a ese punto, la elección entre Redis gestionado y MongoDB gestionado deja de ser una preferencia de base de datos y se convierte en una decisión arquitectónica con consecuencias reales en coste, escalado y operaciones. La documentación genérica de los proveedores cloud rara vez ofrece una respuesta clara. Aquí tienes una.

Para qué está optimizado cada almacén

Redis es un almacén de estructuras de datos en memoria. Todo su conjunto de datos reside en RAM, de ahí que pueda devolver resultados en fracciones de milisegundo. Un estudio publicado en 2025 por IEEE desde la PUCE midió Redis con una latencia media de 7 ms frente a los 50 ms de MongoDB en cargas de trabajo de microservicios comparables. Otro estudio revisado por pares en ResearchGate encontró que Redis alcanza tiempos de lectura medios de 0,00037 segundos, una mejora del 60 % respecto a la línea base de 0,00093 segundos de MongoDB. Estas cifras provienen de entornos académicos controlados, no de producción a escala, pero la dirección es consistente y la física no va a cambiar: la RAM es más rápida que el disco.

MongoDB es una base de datos documental con cumplimiento ACID, un framework de agregación maduro, colecciones de series temporales nativas y change streams. Rinde bien en consultas complejas que Redis simplemente no puede expresar de forma eficiente. El mismo estudio de la PUCE encontró que MongoDB supera a Redis en el tiempo de carga inicial de datos (1,2 segundos frente a 2,7 segundos) y en eficiencia de recursos. MongoDB también implementa sharding de forma más sofisticada que Redis Cluster, algo que importa cuando el conjunto de datos crece más allá de lo que puedes permitirte mantener completamente en memoria.

La división práctica es la siguiente: Redis gana en rendimiento bruto y latencia en búsquedas puntuales; MongoDB gana en complejidad de consultas, garantías de persistencia y volumen de datos. Ninguno es universalmente superior, y los equipos que tienen problemas suelen ser los que eligieron uno e intentaron que hiciera el trabajo del otro.

La durabilidad no es binaria

Una de las diferencias más importantes es cómo gestiona cada almacén la persistencia, y suele subestimarse en el momento del diseño.

El modelo de persistencia predeterminado de Redis utiliza snapshots RDB periódicos. Los datos escritos entre snapshots pueden perderse ante un fallo. Puedes habilitar el registro append-only con fsync síncrono, pero las operaciones de fsync síncrono pueden tardar varios milisegundos, una penalización de rendimiento de entre 10 y 100 veces respecto al modo asíncrono predeterminado. En la práctica, la mayoría de los despliegues de Redis aceptan cierto riesgo de pérdida de datos a cambio de las características de latencia que buscaban. Es un intercambio razonable para una caché o un almacén de sesiones; es un problema serio para cualquier cosa que necesite una pista de auditoría duradera.

Las escrituras de MongoDB son durables por defecto gracias al journaling, y sus transacciones ACID permiten modelar cambios de estado financiero, mutaciones de inventario y escrituras orientadas al usuario sin necesidad de una capa de reconciliación adicional. Si tu analítica en tiempo real alimenta informes posteriores que deben ser fiables, el modelo de persistencia de MongoDB es la base más segura.

Elegir un almacén de datos solo por la latencia es como especificar un coche de carreras para una ruta de reparto. La velocidad importa, pero también importa lo que ocurre cuando paras.

Dónde se divide realmente la carga de trabajo

La analítica en tiempo real no es una sola carga de trabajo. Son varias, y el almacén adecuado depende de la capa que estés construyendo.

Estado de sesión, feature flags y limitación de tasa: Redis es la respuesta correcta. Se trata de lecturas y escrituras de alta frecuencia y baja complejidad sobre objetos pequeños. El modelo en memoria es exactamente el adecuado, y el riesgo de pérdida de datos es aceptable porque el estado es reconstruible o de corta duración.

Clasificaciones en vivo y feeds ordenados: Los Sorted Sets de Redis gestionan esto de forma nativa y eficiente. Obtienes inserciones y consultas de rango en O(log N) sin ninguna sobrecarga de agregación. MongoDB puede modelar esto, pero estarás trabajando contra la lógica del motor.

Dashboards en vivo sobre datos históricos: Las colecciones de series temporales y los pipelines de agregación de MongoDB encajan mejor. Los change streams permiten enviar actualizaciones a los dashboards sin necesidad de polling. Una restricción a tener en cuenta en el diseño: las etapas del pipeline de agregación tienen un límite de memoria de 100 MB por defecto, por lo que las agregaciones costosas necesitan vistas preagregadas o trabajos asíncronos, no consultas en línea en el camino crítico.

Caché de resultados de inferencia de IA y búsqueda vectorial: Redis 8.0 introdujo los Vector Sets como tipo de dato nativo, lo que lo convierte en una opción viable para almacenar y consultar vectores de embeddings con baja latencia. Los benchmarks del proveedor de Redis Ltd. afirman hasta 11 veces más rendimiento en consultas y 14 veces menor latencia en comparación con MongoDB Atlas Search; tómalos como orientativos más que como definitivos, aunque la lógica arquitectónica es sólida. Ejecutamos cargas de trabajo de inferencia en GPU en nuestra infraestructura de IA y consistentemente vemos Redis como la capa de caché adecuada entre el endpoint del modelo y la aplicación, con MongoDB o almacenamiento de objetos gestionando el registro persistente.

Pipelines orientados a eventos que alimentan analítica: Si tu capa de analítica está aguas abajo de un backbone de streaming, la elección del almacén interactúa con tu arquitectura de streaming. El streaming de eventos compatible con Kafka y Redis se combinan de forma natural para vistas materializadas que deben actualizarse con alta frecuencia mediante búsquedas simples por clave. Los change streams de MongoDB funcionan bien cuando la aplicación consumidora necesita un contexto documental más rico en cada evento.

La cuestión de las licencias que no puedes ignorar en 2026

Los equipos de aprovisionamiento en la nube soberana deben entender el panorama de licencias antes de comprometerse con cualquiera de los dos productos a escala.

En marzo de 2024, Redis Ltd. pasó de la licencia BSD a un modelo dual RSALv2/SSPLv1. Bajo RSALv2, ofrecer Redis como servicio gestionado está prohibido sin un acuerdo comercial con Redis Ltd. Esto impulsó la creación de Valkey, un fork de código abierto de Redis 7.2.4 bajo la licencia BSD 3-Clause, respaldado por la Linux Foundation junto con AWS, Google, Oracle y Ericsson. Aiven migró miles de servidores Redis a Valkey tras el cambio.

Redis ha vuelto a moverse desde entonces: Redis 8.0 (mayo de 2025) introdujo un modelo de triple licencia que permite a los usuarios elegir AGPLv3 (código abierto aprobado por OSI) junto con las opciones de código fuente disponible. Redis 8.8, lanzado en mayo de 2026, continúa bajo este modelo. La situación se ha estabilizado en cierta medida, pero cualquier organización que evalúe Redis gestionado debe confirmar qué upstream sigue su proveedor y cuáles son las condiciones comerciales.

MongoDB utiliza SSPL desde 2018. No está aprobado por OSI, pero la restricción práctica recae sobre los proveedores, no sobre los usuarios: los proveedores cloud deben publicar en código abierto su stack para ofrecer MongoDB como servicio gestionado, que es la razón por la que existen alternativas del estilo de DocumentDB.

Para los equipos en nube soberana europea, la cuestión de las licencias se suma a la cuestión de la cadena de suministro. No solo necesitas saber bajo qué licencia opera tu servicio gestionado, sino también quién controla el upstream y bajo qué jurisdicción. Una base de datos gestionada que esté contractual y operativamente bajo legislación europea tiene un perfil de riesgo diferente al de una que enruta los tickets de soporte a través de una entidad matriz estadounidense.

Cómo tomar la decisión

La decisión no suele ser una u otra. La mayoría de los stacks de analítica en producción usan ambos: Redis como capa caliente para lecturas por debajo del milisegundo, datos de sesión y caché; MongoDB como capa templada para documentos persistentes, consultas complejas y registros de series temporales. La pregunta es dónde se sitúa el límite y qué almacén es la fuente de verdad para cada clase de datos.

  • Si necesitas latencia por debajo del milisegundo en búsquedas simples y puedes tolerar persistencia eventual, Redis es el almacén primario adecuado para esa carga de trabajo.
  • Si necesitas agregaciones complejas, garantías ACID o conjuntos de datos que crecen más allá de la RAM que puedes costear, MongoDB es la base correcta.
  • Si estás construyendo un pipeline de analítica orientado a eventos, diseña primero la capa de streaming y deja que el patrón de consumo determine qué almacén encaja como destino.
  • Si operas en infraestructura soberana europea, audita la cadena de licencias y operaciones de ambos antes de comprometerte con cualquiera de ellos a escala.

Ambos están disponibles como servicios gestionados en nuestra plataforma, operados dentro de la jurisdicción europea sin que ningún dato salga del continente. La carga operativa de ejecutar cualquiera de los dos en producción, incluyendo parcheo, configuración de failover y planificación de capacidad, recae en nosotros para que tu equipo pueda centrarse en la carga de trabajo y no en la fontanería.