DocumentDB: Emulación frente a MongoDB

MongoDB es la base de datos líder para el modelo de datos por documentos. Su servicio Atlas está disponible en AWS, Azure y Google Cloud, y su popularidad ha impulsado a otros proveedores a desarrollar APIs compatibles, como Amazon DocumentDB con compatibilidad MongoDB. Microsoft tomó un rumbo similar con CosmosDB y creó una emulación de MongoDB sobre PostgreSQL denominada DocumentDB, ahora acogida por la Linux Foundation. Incluso AWS se ha sumado al proyecto. Hoy, el servicio gestionado Amazon DocumentDB usa su propio motor basado en Aurora, pero la participación de AWS abre la puerta a que en el futuro pueda apoyarse en esta extensión sobre PostgreSQL.

Una emulación no sustituye completamente a MongoDB, diseñado nativamente para almacenar, indexar y procesar documentos con esquema flexible, en lugar de bloques de tamaño fijo y tablas relacionales. Sin embargo, puede facilitar transiciones. Este artículo compara un patrón de consulta simple en tres opciones: MongoDB nativo, PostgreSQL con la extensión DocumentDB y la emulación de Oracle Database con ORDS. Todas afrontan desafíos similares al imponer semántica de documento sobre motores orientados a filas. El objetivo es mostrar un método de evaluación con planes de ejecución, para medir pros y contras frente a patrones de aplicación comunes.

MongoDB

Con una colección con un campo nnn indexado y valores aleatorios entre 0 y 100, la consulta por rango entre 20 y 80, ordenada ascendente y con paginación de 5, se resuelve con eficiencia total. El plan de ejecución muestra IXSCAN en el índice nnn con límites de 20 a 80, lectura de 5 claves y 5 documentos y una etapa LIMIT que detiene al alcanzar el resultado. MongoDB aprovecha que el índice cumple dos funciones simultáneas: filtra por rango y entrega filas ya ordenadas, evitando ordenar y leer más de lo necesario. Un índice cubriente podría incluso eliminar el FETCH, pero no aporta valor cuando la paginación lee pocas filas.

PostgreSQL con DocumentDB

Para comprender la emulación se observan tanto el plan expuesto por la capa Mongo como el plan real en PostgreSQL. Al repetir la misma consulta, la emulación identifica el índice pero no empuja el orden al acceso al índice. El resultado práctico: se leen decenas de miles de entradas del índice, se recuperan los documentos, se ordenan y finalmente se aplica el límite de 5, descartando lo demás. En el plan de PostgreSQL se aprecia un Index Scan sobre un índice RUM extendido, combinado con un operador de rango sobre BSON. El índice se usa para filtrar, pero la ordenación requiere una etapa SORT aparte. La razón de fondo es la semántica multivalor típica del modelo documento: un campo indexado puede ser un arreglo y generar múltiples entradas de índice por documento. En MongoDB, el motor de índices multiclave sabe deduplicar y devolver en orden correcto durante el escaneo. En PostgreSQL este comportamiento no es nativo, por lo que la versión actual de DocumentDB no puede devolver resultados ordenados directamente desde el índice.

La estructura física en PostgreSQL revela tablas shard con Citus y un método de acceso documentdb_rum para índices. En pruebas adicionales con proyección para simular un índice cubriente, la emulación añade una etapa PROJECT pero no logra un Index Only Scan, por lo que continúa leyendo miles de documentos. Este nuevo método de índice nació para ir más allá de las limitaciones de GIN y evoluciona con rapidez, pero aún no iguala el empuje de orden y cobertura que ofrece MongoDB.

Oracle Database con ORDS

La emulación MongoDB de Oracle muestra un patrón similar al de PostgreSQL: no empuja el ORDER BY al índice, realiza un Index Range Scan multivalor con deduplicación mediante HASH UNIQUE y luego un acceso a tabla por ROWID por lotes. En ejecución real se observan alrededor de 80054 entradas de índice leídas con un rango por un solo lado y, tras acceder a la tabla, los filtros por rango reducen a unas 59827 filas antes de ordenar y devolver las 5 primeras. Aunque el acceso batched optimiza IO, la necesidad de deduplicar por la multivaluación y la imposibilidad de mantener el orden natural del índice hasta el resultado final hacen que se lean y ordenen muchos más datos que en MongoDB.

Intentos con ayudas al optimizador modifican detalles del plan, pero evidencian la complejidad de replicar la semántica multiclave y la paginación ordenada propia de MongoDB sobre un SGBD relacional.

Conclusiones

MongoDB se diferencia de los SGBD relacionales en dos ejes. Primero, su API y modelo de documento favorecen el desarrollo dirigido por la aplicación, alineando los datos con los objetos del dominio en lugar de un esquema relacional normalizado. Segundo, esta lógica se mantiene en la capa de almacenamiento, de modo que muchas transacciones de negocio son operaciones únicas sobre un documento, a menudo en un único shard, mejorando simplicidad, rendimiento y escalabilidad.

Emular MongoDB sobre un motor SQL es complejo porque requiere capacidades para las que los RDBMS no fueron concebidos: relaciones uno a muchos embebidas en documentos, índices multiclave con deduplicación y retorno ordenado durante el escaneo, y potencial de índices cubrientes sobre estructuras multivalor. Las emulaciones avanzan con nuevos métodos de índice como el multivalor de Oracle o el RUM extendido de PostgreSQL, pero aún faltan optimizaciones clave como la bajada del ORDER BY al acceso al índice y verdaderos Index Only Scan en escenarios multivalor. En la comparación práctica, DocumentDB sobre PostgreSQL filtra más en el índice que Oracle, pero ambos leen y ordenan más datos que MongoDB nativo para la misma paginación.

La puesta a punto en una emulación exige doble pericia: interpretar planes al estilo MongoDB y, a la vez, entender las estrategias del motor SQL subyacente. Por ello, además del rendimiento, conviene valorar la simplicidad operativa. Las emulaciones son útiles cuando simplifican la vida del equipo, aceptando ciertas limitaciones de funcionalidades o rendimiento a cambio de permanecer en tecnologías conocidas. Si la solución deriva en rodeos constantes, ajustes delicados o planes difíciles de leer, puede ser preferible adoptar una base de datos que soporte de forma nativa el modelo de documentos.

En Q2BSTUDIO ayudamos a empresas a elegir y optimizar su arquitectura de datos para cargas orientadas a documentos, transaccionales o analíticas. Diseñamos aplicaciones a medida y software a medida, integramos pipelines de datos y optimizamos índices y particiones, siempre con foco en rendimiento, seguridad y escalabilidad. Si buscas impulsar nuevos productos digitales o modernizar tu stack, nuestro equipo combina experiencia en desarrollo, ia para empresas, agentes IA, ciberseguridad, servicios inteligencia de negocio y power bi.

Podemos acompañarte con estrategias multicloud y despliegues gestionados, desde clusters nativos hasta entornos serverless, incluyendo mejores prácticas de observabilidad, automatización de despliegues y políticas de backup y recuperación. Consulta nuestros servicios cloud aws y azure y descubre cómo aceleramos la entrega con entornos reproducibles, escalables y seguros. Si además necesitas un producto totalmente adaptado a tu operativa, explora nuestro enfoque de aplicaciones a medida con arquitecturas modulares y pruebas automatizadas desde el primer día.

También te ayudamos a evaluar cuándo una emulación de MongoDB puede ser suficiente y cuándo conviene migrar a un motor nativo. Definimos criterios de decisión basados en patrones de acceso, cardinalidad, uso de arrays, necesidad de índices multiclave, latencia esperada por paginación y coste de mantenimiento. Nuestro objetivo es que tu plataforma crezca con tu negocio, con bases sólidas en inteligencia artificial, ciberseguridad y analítica avanzada que garanticen confiabilidad a largo plazo.