Cuando MongoDB no debería ser tu base de datos principal

 Hay una escena que se repite con demasiada frecuencia: alguien elige MongoDB como base principal, el equipo empieza a modelar “como siempre”, el sistema crece, y un día la base deja de sentirse ligera y empieza a sentirse como un experimento caro. No porque el motor sea incapaz, sino porque el dominio real del sistema nunca dejó de ser relacional, aunque lo hayas guardado en documentos.

A muchos nos enseñaron lo mismo. Bases de datos relacionales con fundamentos formales: álgebra relacional, teoría de conjuntos, normalización, formas normales, integridad. Nos enseñaron a pensar en consistencia estructural como algo que el motor te ayuda a garantizar. Ese entrenamiento funciona, y funciona muy bien, pero tiene un efecto secundario: cuando llegas al mundo documental, tu instinto es recrear el mundo relacional con otras herramientas.

Y ahí empieza el problema.

La mayoría de errores que he visto con MongoDB no nacen de MongoDB. Nacen de diseños que intentan usar colecciones como si fueran tablas y referencias como si fueran llaves foráneas. En un dominio pequeño, con pocas colecciones y accesos simples, eso puede parecer correcto. La ilusión dura lo suficiente como para que el sistema se vuelva serio. Luego llega la correlación real entre entidades, la necesidad de cruzar datos, y el precio aparece.

Cuando modelas relacional en Mongo, la relación no desaparece. Se convierte en trabajo de consulta.

Empiezas a encadenar agregaciones, $lookup tras $lookup, pipelines que crecen por capas, etapas que materializan datos en memoria y consumen CPU de forma poco predecible. A veces no es que tarde más. A veces consume tanto que falla. Y cuando falla, lo peor no es el fallo: es la opacidad. Hay errores que no te dicen nada sobre el problema real del diseño. Solo ves síntomas del motor.

Un ejemplo muy concreto de esto lo viví en un sistema real.

Teníamos varias colecciones principales con _id como ObjectId, que es lo normal en Mongo. Pero en colecciones relacionadas, por comodidad histórica o desconocimiento, esos mismos identificadores se guardaban como string. En el código en C# eso nunca explotó: el driver convertía todo a string y el sistema “funcionaba”.

Hasta que empezamos a hacer agregados serios.

Los $lookup no encontraban nada.

No fallaban.
No lanzaban error.
No avisaban de incompatibilidad de tipos.

Simplemente devolvían cero resultados.

Desde el punto de vista del motor, no había ningún problema. La consulta era válida. La semántica estaba rota, pero Mongo no tiene forma de protegerte de eso. No hay integridad referencial, no hay validación cruzada, no hay advertencia. Solo silencio.

Depurar eso fue arqueología.

Y este tipo de fallos no son raros. Son estructurales. En Mongo, el esquema no desaparece: se desplaza. Ya no está en el motor, está en la disciplina del equipo. En convenciones implícitas. En contratos frágiles entre servicios. En tipos que nadie valida de forma global.

El problema no se queda en producción. Se agrava cuando el negocio te pide entender tus propios datos.

Porque tarde o temprano alguien va a querer dashboards, métricas, analítica. Y entonces sucede algo que rara vez se dice en voz alta: muchos sistemas cuyo core está en Mongo terminan exportando datos para reconstruirlos en SQL. Extraes, transformas, y llevas a un motor relacional o a un lago consultable con SQL. En AWS, por ejemplo, no es raro terminar consultando esos datos con Athena y construyendo dashboards en QuickSight.

Da igual el stack. El patrón es el mismo.

Diseñas desnormalizado para que el runtime funcione.
Luego tienes que normalizar para poder entender el negocio.

Sostienes dos modelos distintos de la misma realidad.

Si desnormalizaste con criterio, el costo existe pero es manejable.
Si desnormalizaste mal, reconstruir después es un infierno.
Si además diseñaste como si Mongo fuera relacional, pagas dos veces: en agregaciones pesadas y en analítica rota.

Aquí hay un problema más profundo, y es pedagógico.

A casi todos nos enseñaron a normalizar. Casi nadie nos enseñó a desnormalizar como disciplina. La desnormalización no es una licencia para duplicar datos sin pensar. Es una técnica con trade-offs muy duros: compras rendimiento a cambio de coherencia. Y si no tienes un criterio sólido para esa coherencia, la base se convierte en un conjunto de documentos “correctos por costumbre”, hasta que el sistema crece y la costumbre falla.

Por eso, usar MongoDB como base primaria no es una decisión neutra.

Si tu dominio es intensamente relacional, si sabes que vas a cruzar entidades, si necesitas auditoría, reporting serio, explotación analítica, Mongo te va a empujar casi inevitablemente a un patrón que he visto demasiadas veces: diseño relacional disfrazado de documental, consultas que se vuelven un motor dentro del motor, y un pipeline posterior hacia SQL para poder entender lo que tú mismo construiste.

No es una condena a Mongo. Es un criterio de arquitectura.

Mongo es excelente para ciertos roles: eventos, estados agregados, catálogos simples, proyecciones materializadas, vistas de consulta, datos sin integridad cruzada fuerte. Pero si lo que tienes es un sistema con relaciones reales y consecuencias reales, tal vez lo más honesto desde el inicio sea aceptar algo muy simple:

tu fuente de verdad es relacional, aunque el hype del momento te diga otra cosa.