MongoDB frente a DynamoDB: compensaciones nativas de la nube

AWS DynamoDB y MongoDB Atlas son bases de datos NoSQL en la nube, pero siguen filosofías muy diferentes. DynamoDB es el servicio NoSQL completamente sin servidor de AWS: no hay servidores que administrar, ofrece escalado automático y un modelo de precios basado en solicitudes. MongoDB Atlas es un servicio gestionado en la nube, pero sigue basándose en clústeres de servidores con un control operativo más amplio. La elección suele reducirse a dos preguntas: ¿cuánto control desea sobre la infraestructura y qué complejidad tienen sus patrones de consulta?

DynamoDB es realmente sin servidor: no hay instancias que elegir, decisiones sobre el tamaño del clúster ni configuración de conjuntos de réplicas. AWS escala automáticamente la capacidad de lectura y escritura según la demanda, gestiona la fragmentación de forma transparente y garantiza una latencia de un solo dígito en milisegundos a cualquier escala. Para los equipos que desean una carga operativa nula y una integración estrecha con AWS (roles de IAM, activadores de Lambda y Streams), DynamoDB elimina toda una categoría de decisiones de infraestructura.

El modelo de acceso principal de DynamoDB es limitado: cada tabla tiene una clave de partición (obligatoria) y una clave de ordenación opcional. Los elementos se recuperan mediante una coincidencia exacta de la clave de partición y, opcionalmente, se filtran por un rango de la clave de ordenación. No existe un motor de consultas de propósito general: las consultas ad hoc requieren un Global Secondary Index (GSI) diseñado al crear la tabla o un Scan de la tabla completa (costoso y lento). Esto obliga a diseñar el esquema priorizando los patrones de acceso, de forma similar a Cassandra.

MongoDB Atlas admite el mismo modelo de consultas avanzado que MongoDB autogestionado: pipelines de agregación, uniones mediante $lookup, búsqueda de texto, consultas geoespaciales y filtros sobre cualquier campo con índices compuestos. Los patrones de consulta pueden evolucionar después del lanzamiento con solo añadir un índice nuevo. Esta flexibilidad supone una gran ventaja para las aplicaciones cuyos requisitos cambian con frecuencia o no se conocen por completo al diseñarlas.

DynamoDB ofrece dos modalidades de precios: bajo demanda (paga por cada solicitud de lectura o escritura; es ideal para tráfico impredecible) y aprovisionada (reserve unidades de capacidad por adelantado; resulta más económica para cargas predecibles con escalado automático). MongoDB Atlas cobra según el nivel del clúster (tamaño de la instancia y almacenamiento), lo que hace que los costes sean más predecibles con una carga constante, pero más altos con poco tráfico. Para cargas variables o controladas por eventos, sin tráfico entre eventos, el pago por solicitud de DynamoDB puede ser considerablemente más económico.

DynamoDB se integra de forma nativa con el ecosistema más amplio de AWS. DynamoDB Streams emite eventos de cambio que activan funciones de AWS Lambda, de forma idéntica a MongoDB Change Streams, pero dentro de AWS. La autenticación de IAM evita tener que gestionar credenciales de base de datos independientes. La recuperación a un momento dado y las copias de seguridad se configuran con unos pocos clics. Para los equipos que ya dependen en gran medida de AWS (Lambda, API Gateway, Cognito, S3), DynamoDB reduce al mínimo el cambio de contexto.

MongoDB Atlas se ejecuta en AWS, Azure y GCP, por lo que no queda vinculado a un único proveedor de nube. Puede implementar un clúster multirregional que abarque AWS y Azure. MongoDB autogestionado en sus propios servidores se comporta de forma idéntica a Atlas, por lo que puede migrar entre la nube y las instalaciones locales. DynamoDB solo está disponible en AWS; migrar a otro proveedor requiere reescribir la capa de acceso a los datos. Para las organizaciones con estrategias multinube o requisitos normativos de residencia de datos, la portabilidad de Atlas supone una ventaja importante.

DynamoDB ofrece lecturas eventualmente consistentes (opción predeterminada; menor latencia y menor coste) y lecturas fuertemente consistentes (mayor latencia y el doble de coste). Las escrituras siempre son fuertemente consistentes dentro de un único elemento. DynamoDB también admite transacciones (TransactWriteItems / TransactGetItems) para realizar operaciones atómicas en varios elementos, con un máximo de 100 elementos por transacción. Son similares a las transacciones multidocumento de MongoDB, pero se facturan al doble del coste normal de las unidades de lectura y escritura.

Ambas bases de datos admiten documentos flexibles y sin esquema. Los elementos de DynamoDB pueden tener hasta 400 KB; los documentos de MongoDB, hasta 16 MB. Para metadatos de contenido multimedia enriquecidos, textos largos o estructuras anidadas grandes, el límite de documentos más amplio de MongoDB es importante. El límite de 400 KB de DynamoDB implica que las cargas grandes deben dividirse o almacenarse en S3 junto con una referencia en DynamoDB, lo que añade complejidad. Para los datos estructurados habituales de menos de 400 KB, el límite rara vez supone un problema.

Elija DynamoDB cuando su equipo sea nativo de AWS y quiera olvidarse por completo de la gestión de la infraestructura; el tráfico sea variable o impredecible (API respaldadas por Lambda, sistemas controlados por eventos); sus patrones de acceso sean sencillos y estén bien definidos de antemano (búsquedas de clave-valor y rangos ordenados); o necesite una integración estrecha con Lambda/IAM sin gestionar grupos de conexiones. Las aplicaciones de una sola página con una API REST y operaciones CRUD sencillas sobre DynamoDB son casos de uso clásicos.

Elija MongoDB Atlas cuando los patrones de consulta evolucionen o sean complejos (agregaciones, uniones, búsqueda de texto completo); su equipo necesite portabilidad entre nubes o instalaciones locales; los documentos puedan ser mayores de 400 KB; necesite Atlas Search, Vector Search o Data Federation; o su aplicación ya utilice MongoDB localmente y quiera migrarla a la nube sin fricciones. MongoDB también es la opción más sólida si las canalizaciones de análisis enriquecido son un requisito fundamental.

En esta lección ha aprendido que el modelo sin servidor y la integración nativa con AWS de DynamoDB lo hacen ideal para cargas variables controladas por eventos con patrones de acceso sencillos y predefinidos; que MongoDB Atlas ofrece consultas más completas, documentos más grandes y portabilidad multinube, ventajas que DynamoDB no puede igualar; y que la principal disyuntiva es la simplicidad operativa y la dependencia de AWS (DynamoDB) frente a la flexibilidad de consulta y la libertad entre nubes (MongoDB). A continuación, veremos cuándo utilizar una base de datos de grafos como Neo4j en lugar de MongoDB.