El anuncio de DuckDB v2.0, presentado en agosto de 2026 y previsto para septiembre de ese mismo año, ha intensificado un debate que muchos equipos de infraestructura llevan tiempo teniendo en silencio: ¿estamos usando la base de datos correcta para análisis, o simplemente la que ya teníamos en marcha? MongoDB es una opción legítima para una amplia variedad de cargas de trabajo, pero el análisis a escala es donde la respuesta se complica. A continuación, un análisis honesto de cuándo un document store gestionado justifica su lugar y cuándo un motor diseñado específicamente para análisis lo dejará atrás.

Para qué está diseñado realmente MongoDB

MongoDB almacena datos en BSON, un formato JSON binario, y su motor de consultas fue diseñado para recuperar documentos específicos o subconjuntos de una colección. Ese diseño es genuinamente excelente para cargas de trabajo operacionales: esquemas flexibles, escalado horizontal, búsquedas puntuales rápidas y la capacidad de evolucionar un modelo de datos sin migraciones costosas. Para aplicaciones que escriben con frecuencia y leen de forma selectiva, la arquitectura de MongoDB encaja muy bien.

El aggregation pipeline extiende MongoDB hacia el terreno analítico y, para complejidad baja o media, funciona bien. Pero las limitaciones son reales y están documentadas. Las etapas del pipeline están limitadas a 100 MB de RAM antes de que MongoDB falle o vuelque a disco, momento en el que la latencia aumenta en órdenes de magnitud. El operador $lookup imita los joins, pero con millones de documentos se vuelve lento y consume mucha memoria. Map-reduce quedó obsoleto en MongoDB 5.0. El límite del pipeline se sitúa en 1.000 etapas. No son casos extremos; son los límites de un sistema diseñado para recuperar documentos, no para agregaciones a gran escala.

MongoDB 8.0 introdujo mejoras significativas para un patrón analítico específico: las series temporales. Block Processing for Time Series Collections aplica un modelo de ejecución columnar a etapas de agregación como $match, $group y $setWindowFields, procesando bloques de datos en lugar de un documento a la vez. Tasas de compresión del 70 al 90 por ciento sobre datos brutos de series temporales suponen una ventaja operacional real. Si tu carga de trabajo analítica es principalmente de series temporales, MongoDB 8.0 cierra una brecha importante.

Dónde el análisis con MongoDB se rompe a escala

El patrón que más problemas genera es el que al principio parece inocente: un dashboard de reporting o una API analítica construida directamente sobre una colección operacional de MongoDB. A pequeña escala funciona bien. A medida que los datos crecen, aparecen escaneos de colección porque los índices no cubren la forma de la agregación, el $unwind sobre arrays grandes se vuelve costoso y la presión de memoria en las etapas de agregación empieza a producir errores o fuerza volcados a disco. La solución habitual es trasladar la agregación a una réplica de lectura y ajustar cuidadosamente el orden de las etapas, pero eso es esfuerzo de ingeniería aplicado a un problema que un motor columnar no tendría desde el principio.

El aggregation pipeline es una herramienta capaz para el reporting operacional. No es un motor OLAP, y tratarlo como tal acabará costándote más en tiempo de ajuste del que habría costado configurar una solución diseñada para ese fin.

La distinción importa porque los dos patrones de consulta son estructuralmente diferentes. Las consultas OLAP escanean grandes porciones de un conjunto de datos, filtran en múltiples dimensiones y agregan a través de millones de filas. Los document stores están optimizados para recuperar rápidamente un número reducido de documentos. Las mejoras columnares de MongoDB en series temporales son un paso hacia ese puente, pero se aplican a un tipo de colección específico, no a la agregación general sobre colecciones de documentos arbitrarias.

Qué señala DuckDB v2.0 sobre el rumbo del análisis de datos

DuckDB es un RDBMS embebido y orientado a columnas, diseñado para consultas OLAP de alto rendimiento. Su motor vectorizado procesa datos en bloques de 256 tuplas usando instrucciones SIMD, lo que significa que las agregaciones complejas sobre grandes conjuntos de datos se ejecutan rápido sin necesidad de un proceso de servidor separado. La versión 1.0 se publicó en junio de 2024; la línea 1.x ha incorporado desde entonces versiones LTS, un tipo VARIANT nativo para datos semiestructurados y mejoras de rendimiento continuas.

La versión v2.0 planificada, presentada por el equipo de DuckDB en agosto de 2026, no es un cambio de versión cosmético. Incluye un nuevo parser SQL, un nuevo formato de almacenamiento por defecto, una C API rediseñada y lo que el equipo ha descrito como el inicio de «el año de DuckDB como servidor». Ese enfoque es relevante: DuckDB ha sido históricamente una herramienta embebida de proceso único. La dirección de v2.0 indica que el proyecto avanza hacia casos de uso que se parecen más a un servidor de análisis ligero, no solo a una biblioteca que se embebe en un script de Python.

La consecuencia práctica para los equipos que usan MongoDB para análisis es que la alternativa es cada vez más fácil de operar, no más difícil. Un motor OLAP embebido y ligero capaz de consultar archivos Parquet, JSON y ahora datos semiestructurados VARIANT directamente es un sustituto creíble de un aggregation pipeline de MongoDB que ha sido forzado más allá de su caso de uso natural.

El caso del MongoDB gestionado que sigue siendo válido

Nada de esto significa que MongoDB sea la elección incorrecta. Significa que el análisis puro es el caso de uso equivocado sobre el que anclar la decisión. Las situaciones donde el MongoDB gestionado realmente justifica su lugar son las cargas de trabajo mixtas: aplicaciones que escriben datos operacionales de forma continua y necesitan análisis sobre subconjuntos recientes de esos datos, sin la sobrecarga de un pipeline ETL separado hacia un data warehouse. Para esas cargas de trabajo, el patrón de réplica de lectura, combinado con los índices secundarios de MongoDB y las mejoras de block processing para series temporales de la versión 8.0, aporta valor real.

El otro caso sólido es la flexibilidad de esquema en el momento de la ingesta. Cuando las fuentes de datos upstream son heterogéneas y están en evolución, un document store absorbe esa variabilidad sin migraciones de esquema. Si las consultas analíticas se limitan a datos recientes o a subconjuntos específicos de documentos, el aggregation pipeline de MongoDB es suficientemente rápido y operacionalmente más sencillo que mantener un almacén columnar separado.

Gestionamos MongoDB en toda nuestra infraestructura europea, y las cargas de trabajo donde rinde de forma fiable son exactamente estas: datos operacionales con reporting en tiempo real sobre ventanas recientes, no escaneos analíticos sobre tablas completas. Nuestros 44 puntos de presencia en Europa y Oriente Medio, con peering directo a AWS, Azure, GCP, Oracle y Cloudflare en cada ubicación, significan que las aplicaciones que consultan MongoDB junto a servicios de hiperscaladores no pagan una penalización de latencia por el round trip. Eso importa cuando construyes una API de reporting que agrega desde MongoDB y enriquece desde un servicio de datos en la nube en el mismo flujo de solicitud.

Cómo tomar la decisión: un árbol de decisión práctico

  • Tus consultas escanean millones de documentos y agregan en muchas dimensiones: MongoDB tendrá problemas. Un motor columnar como DuckDB, ClickHouse o un data warehouse gestionado es la herramienta adecuada.
  • Tu análisis es sobre datos recientes de una colección operacional de MongoDB: Las réplicas de lectura y un ajuste cuidadoso del pipeline funcionarán. MongoDB gestionado es una opción razonable.
  • Tus datos son series temporales con altas tasas de ingesta: Las Time Series Collections de MongoDB 8.0 con Block Processing son ahora una opción legítima junto a las bases de datos de series temporales diseñadas específicamente para ese fin.
  • Necesitas flexibilidad de esquema en la ingesta y análisis ligero sobre esos datos: El modelo de documentos de MongoDB justifica su lugar. No añadas un warehouse hasta que el aggregation pipeline se convierta en el cuello de botella.
  • Ejecutas consultas tanto operacionales como analíticas sobre la misma colección a escala: Separa las responsabilidades. Usa MongoDB para escrituras y lecturas operacionales; exporta a un almacén columnar para el análisis.

El error que cometen la mayoría de los equipos no es elegir MongoDB incorrectamente al principio. Es no revisar esa decisión a medida que crece el volumen de datos. El aggregation pipeline que gestionaba el reporting con 10 millones de documentos no lo hará igual con 500 millones, y el momento de diseñar una separación es antes del primer incidente en producción, no después.