La bifurcación arquitectónica entre Redis y MongoDB para la gestión de sesiones y estado parece engañosamente simple sobre el papel. Redis es rápido; MongoDB es persistente. Elige uno y sigue adelante. En la práctica, la decisión toca presupuestos de latencia, garantías de durabilidad, postura ante licencias y dónde residen legalmente tus datos, y los benchmarks genéricos rara vez capturan cómo se acumulan esas compensaciones cuando ejecutas cargas de trabajo con estado en regiones europeas.

Ambos almacenes figuran entre los seis primeros en DB-Engines a abril de 2026 (MongoDB en el quinto puesto, Redis en el sexto), lo que indica que el ecosistema es maduro en ambos lados. Esa madurez tiene doble filo: hay mucha sabiduría convencional que no sobrevive al contacto con una carga de trabajo real de estado de sesión.

Qué estás optimizando realmente

El estado de sesión tiene un perfil específico: lecturas y escrituras pequeñas, frecuentes y sensibles a la latencia; requisitos de durabilidad variables según la aplicación; y un volumen de datos por sesión que rara vez es suficientemente grande como para estresar un modelo de documentos. Ese perfil le sienta bien a Redis, pero también expone su punto más débil.

Redis 7.4 es un almacén en memoria de clave-valor y estructuras de datos con latencia de submilisegundo en condiciones normales de operación. Si una instancia de Redis que almacena datos solo en RAM se reinicia sin persistencia configurada, todos los datos de sesión desaparecen. Para un carrito de compra o un token de autenticación efímero, eso puede ser aceptable. Para un flujo de trabajo financiero regulado o una sesión de salud con estado de formulario en progreso, no lo es.

MongoDB almacena datos en disco mediante el motor de almacenamiento WiredTiger. Las escrituras son durables por defecto; no es necesario pensar por separado en si la persistencia está activada. La compensación es que las operaciones respaldadas en disco tienen mayor latencia que las operaciones en memoria, y para lecturas de sesión de alta frecuencia a escala, esa diferencia importa.

Persistencia en Redis: la configuración que lo cambia todo

La brecha de durabilidad entre los dos almacenes es real, pero es configurable en el lado de Redis. Redis ofrece tres modos de persistencia: RDB (instantáneas puntuales a intervalos especificados), AOF (archivo de solo escritura que registra cada escritura y la reproduce al inicio) y un modo combinado RDB más AOF. La persistencia también puede desactivarse por completo para casos de uso de caché pura.

La durabilidad de AOF se controla mediante el parámetro appendfsync. El valor por defecto, appendfsync everysec, significa que puedes perder como máximo un segundo de escrituras en caso de fallo. appendfsync always es la opción más segura, registrando cada escritura de inmediato, pero bajo cargas de escritura elevadas, las operaciones frecuentes de fsync degradan el rendimiento de forma notable. appendfsync no delega el vaciado al sistema operativo y es la opción más rápida pero menos fiable.

El modo de persistencia correcto en Redis no es una pregunta sobre Redis: es una pregunta sobre cuánto le cuesta a tu aplicación y a tus usuarios perder una sesión.

Para la mayoría de las cargas de trabajo de sesión web, everysec con replicación a un conjunto de réplicas es un compromiso razonable. Para cualquier caso que requiera durabilidad estricta, o bien pasas a always y aceptas el coste en rendimiento, o reconsideras si Redis es realmente el almacén de sesiones primario adecuado.

Cuándo MongoDB tiene más sentido para el estado de sesión

MongoDB se convierte en la opción más sólida cuando los objetos de sesión son complejos: estructuras anidadas, esquemas variables entre tipos de usuario o sesiones que contienen metadatos consultables. Su modelo de documentos maneja todo eso de forma nativa, y evitas la sobrecarga de serialización que supone aplanar un objeto rico en un hash o cadena de Redis.

Si ya ejecutas MongoDB como almacén de datos principal, también existe un argumento arquitectónico para consolidar. La caché interna de WiredTiger puede acomodar un conjunto de trabajo que se ajuste al patrón de lectura de sesiones, y MongoDB Enterprise Advanced ofrece un motor de almacenamiento en memoria si necesitas reducir aún más la brecha de latencia. Añadir Redis a un despliegue de MongoDB existente no es gratuito: introduce una segunda superficie operativa, una segunda disciplina de copia de seguridad y restauración, y un segundo modo de fallo que instrumentar.

Muchas arquitecturas en producción terminan combinando ambos: MongoDB como sistema de registro y Redis como capa de rendimiento para datos de sesión activos y tokens de corta duración. Es un patrón legítimo, pero debería ser una elección deliberada y no la opción por defecto porque alguien añadió Redis para resolver un problema de latencia sin cuestionar si el modelo de datos subyacente era el problema real.

Licencias: la pregunta que cambió en 2024

Las licencias importan en la contratación de infraestructura soberana, y la situación de las licencias de Redis cambió significativamente en los últimos dos años.

En marzo de 2024, Redis Ltd. pasó de BSD a una licencia dual bajo RSALv2 y SSPLv1 a partir de la versión 7.4. Ninguna de las dos está aprobada por la OSI. En respuesta, la Linux Foundation, AWS, Google, Oracle, Ericsson y otros bifurcaron Redis 7.2.4 en Valkey bajo la licencia BSD 3-Clause. Valkey es ahora el motor por defecto para las nuevas instancias de AWS ElastiCache y MemoryDB, y está disponible en Google Cloud Memorystore.

En mayo de 2025, Redis 8.0 añadió AGPLv3 como tercera opción de licencia junto a RSALv2 y SSPLv1, devolviendo a Redis el estatus de código abierto aprobado por la OSI según esa definición. AGPLv3 exige la divulgación del código fuente para servicios accedidos por red, lo que tiene implicaciones para las organizaciones que ejecutan Redis 8 como servicio gestionado interno; las consecuencias operativas y legales precisas de ese requisito no están completamente definidas y conviene revisarlas con tu equipo legal antes de comprometerte con Redis 8 en infraestructura privada.

MongoDB utiliza SSPL desde 2018, por lo que tampoco está aprobado por la OSI. Para los equipos de contratación con políticas de licencias de código abierto, ninguno de los dos almacenes es limpio sin matices; la pregunta es qué restricción de licencia puede gestionar tu organización.

Soberanía y dónde residen realmente los datos

Para los equipos que trasladan cargas de trabajo con estado a infraestructura soberana, la capa de servicio gestionado importa tanto como el modelo de datos. Ejecutar cualquiera de los dos almacenes en infraestructura que en última instancia está sujeta a jurisdicción extranjera vuelve a introducir la exposición que intentabas eliminar.

MongoDB Atlas ha ampliado su cobertura de regiones europeas y ofrece fragmentación basada en zonas que enruta poblaciones de usuarios específicas a regiones geográficas designadas sin cambios en la aplicación. También cuenta con certificaciones ISO 27001, SOC 2 y PCI DSS. Sin embargo, dado que MongoDB Inc. es una empresa estadounidense, la US CLOUD Act potencialmente permite a las autoridades estadounidenses exigir la divulgación de datos independientemente de dónde esté físicamente alojado un clúster de Atlas. Esta es una interpretación legal controvertida, no derecho consolidado, pero es una preocupación documentada que los sectores regulados toman en serio al evaluar si Atlas satisface sus requisitos de residencia de datos.

En DIVERSITY ejecutamos Redis gestionado y MongoDB gestionado sobre infraestructura que reside íntegramente bajo jurisdicción europea. Para cargas de trabajo de sesión sensibles a la latencia que sirven a usuarios del noroeste de Europa, AMS1 en Ámsterdam ofrece interconexión densa a través de AMS-IX y un alcance de menos de 10 ms en Benelux, el Reino Unido y los mercados de Europa occidental, lo que importa cuando las lecturas de sesión están en la ruta crítica de cada solicitud autenticada. El límite legal no se desplaza en función de dónde se encuentre físicamente el rack de un hiperescalador.

Un marco de decisión práctico

Elige Redis gestionado para el estado de sesión cuando: las sesiones son pequeñas y estructuralmente simples, la latencia de lectura de submilisegundo es un requisito estricto, la pérdida de datos aceptable en caso de fallo puede acotarse a un segundo o menos, y tienes la capacidad operativa para configurar y monitorizar la persistencia correctamente.

Elige MongoDB gestionado para el estado de sesión cuando: los objetos de sesión son complejos o de esquema variable, ya ejecutas MongoDB y quieres consolidar la superficie operativa, la durabilidad debe estar garantizada sin configuración adicional, o los datos de sesión necesitan ser consultables para auditoría o análisis.

Elige ambos de forma deliberada cuando: necesitas lecturas a velocidad Redis para sesiones activas y durabilidad a nivel MongoDB para el historial de sesiones o el procesamiento posterior, y estás preparado para operar dos almacenes con disciplinas separadas de copia de seguridad, monitorización y conmutación por error.

Vale la pena abordar directamente la cuestión de los benchmarks: no existe en la literatura pública ningún benchmark independiente, actualizado y multirregional europeo que compare los dos almacenes en cargas de trabajo de estado de sesión. Las cifras publicadas por los proveedores (incluidas las comparaciones del propio Redis Ltd. frente a Atlas) utilizan cargas de trabajo de búsqueda vectorial, no de estado de sesión, y los benchmarks de terceros más antiguos usaban versiones de software de 2017. Prueba con tu propio perfil de sesión, en tu región objetivo, antes de tratar cualquier cifra publicada como autorizada para tu arquitectura.