¿Qué es NoSQL?

Durante décadas, "base de datos" fue sinónimo de "tablas relacionales con SQL". A finales de los 2000, empresas como Google, Amazon y Facebook necesitaron guardar cantidades enormes de datos de formas que las tablas no resolvían bien, y nacieron las bases NoSQL. En esta lección entenderás qué son, sus cuatro grandes familias, cómo se comparan con las relacionales y, lo más importante, cuándo usar MongoDB y cuándo no.

Concepto

NoSQL significa "Not only SQL" (no solo SQL). Agrupa a las bases de datos que no usan el modelo relacional de tablas. No es una tecnología concreta, sino una familia muy diversa.

Analogía: una base relacional es como un archivero con formularios impresos: cada cliente llena exactamente los mismos campos y los formularios de distintos cajones se relacionan por número de folio. Una base de documentos como MongoDB es como una carpeta por cliente: dentro metes todo lo relacionado con él (datos, direcciones, historial), y cada carpeta puede tener papeles distintos.

txt

RELACIONAL (3 tablas)                         DOCUMENTOS (1 documento)
clientes                                      {
┌────┬───────────┐                              "_id": 1,
│ id │ nombre    │                              "nombre": "Ana López",
│ 1  │ Ana López │                              "direcciones": [
└────┴───────────┘                                { "ciudad": "CDMX", "cp": "06600" },
direcciones                                       { "ciudad": "Puebla", "cp": "72000" }
┌────┬────────────┬────────┐                    ],
│ id │ cliente_id │ ciudad │                    "telefonos": ["5511111111"]
│ 1  │ 1          │ CDMX   │                  }
│ 2  │ 1          │ Puebla │
└────┴────────────┴────────┘
telefonos ...

Las cuatro familias de NoSQL

Tipo	Cómo guarda	Ejemplos	Ideal para
Documentos	Documentos tipo JSON agrupados en colecciones	MongoDB, Firestore, CouchDB	Catálogos, contenido, perfiles, apps web y móviles
Clave-valor	Un diccionario gigante: clave → valor	Redis, DynamoDB, Memcached	Caché, sesiones, carritos, contadores, colas
Columnar (column-family)	Filas con columnas dinámicas agrupadas en familias	Cassandra, HBase, ScyllaDB	Escrituras masivas, series de tiempo, IoT a gran escala
Grafos	Nodos y relaciones	Neo4j, Amazon Neptune	Redes sociales, recomendaciones, detección de fraude

txt

Clave-valor (Redis)           Grafo (Neo4j)
"sesion:abc123" → {...}       (Ana)──AMIGA_DE──►(Luis)
"carrito:42"    → [...]          │                 │
"visitas:home"  → 15230       COMPRÓ            COMPRÓ
                                 ▼                 ▼
                              (Teclado)◄──SIMILAR──(Monitor)

En proyectos web reales es común combinar varias: PostgreSQL o MongoDB como base principal y Redis como caché.

Relacional vs documentos

Aspecto	Relacional (MySQL, PostgreSQL)	Documentos (MongoDB)
Unidad	Fila en una tabla	Documento en una colección
Esquema	Fijo, definido antes (`CREATE TABLE`)	Flexible; se puede validar opcionalmente
Relaciones	Claves foráneas + JOINs	Datos embebidos o referencias + `$lookup`
Integridad referencial	Garantizada por la BD	Responsabilidad de la aplicación
Lenguaje	SQL (estándar)	API propia (métodos JS, pipeline de agregación)
Transacciones	ACID maduras desde siempre	ACID en un documento siempre; multi-documento desde la versión 4.0
Escalado	Vertical + réplicas de lectura (horizontal posible pero complejo)	Horizontal nativo (sharding)
Cambios de estructura	Migraciones (`ALTER TABLE`)	Documentos nuevos con campos nuevos, sin migrar todo
Encaja con	Datos muy relacionados y estructurados	Datos jerárquicos o variables, leídos "en bloque"

Equivalencias de vocabulario:

SQL	MongoDB
Base de datos	Base de datos
Tabla	Colección
Fila	Documento
Columna	Campo
Clave primaria	`_id`
JOIN	Documento embebido o `$lookup`
`GROUP BY`	`$group` (agregación)
Índice	Índice

El teorema CAP (versión corta)

En un sistema distribuido (datos repartidos en varios servidores), cuando la red falla entre ellos (Partición), hay que elegir entre:

Consistencia: todos ven el mismo dato al mismo tiempo (aunque algunos no puedan responder).
Disponibilidad (Availability): todos responden siempre (aunque algunos con datos un poco viejos).

txt

          Consistencia
              /\
             /  \        Con una partición de red
            /    \       solo puedes garantizar dos.
           / CP   \      MongoDB (por defecto): CP
          /        \     Cassandra: AP
         /    AP    \
        ──────────────
 Disponibilidad    Tolerancia a particiones

MongoDB, con su configuración por defecto (escrituras al nodo primario), prioriza la consistencia. En la práctica, para un proyecto de un solo servidor o un cluster pequeño de Atlas, CAP casi no te afecta; es útil conocerlo para entender por qué existen distintas bases NoSQL.

Ventajas de MongoDB

Modelo natural para JavaScript: un documento es prácticamente un objeto JS. Sin "traducir" entre objetos y tablas.
Esquema flexible: agregar un campo no requiere migrar millones de filas.
Lecturas rápidas de datos agregados: un pedido con sus productos embebidos se lee con una sola consulta, sin JOINs.
Escalado horizontal con sharding cuando el volumen lo exige.
Atlas: cluster gratuito en la nube, respaldos, búsqueda de texto (Atlas Search) y búsqueda vectorial para IA.
Framework de agregación muy potente para reportes.

Desventajas y riesgos

Sin JOINs eficientes "por defecto": $lookup existe pero no reemplaza a un buen JOIN relacional en consultas muy cruzadas.
Integridad referencial manual: nada impide guardar un pedido con un clienteId que no existe.
Duplicación de datos: embeber implica copiar datos (por ejemplo, el nombre del producto en cada pedido) y mantenerlos coherentes.
"Esquema flexible" mal entendido = datos caóticos: documentos con precio como texto, otros como número, otros sin precio.
Consultas analíticas muy complejas suelen ser más simples en SQL.

Mito: "NoSQL no tiene esquema"

Tus datos siempre tienen un esquema; la pregunta es dónde se define. En SQL lo impone la base de datos. En MongoDB lo impones tú: con validación $jsonSchema, con Mongoose o con disciplina en el código. Sin eso, en seis meses tendrás documentos inconsistentes y errores difíciles de rastrear.

¿Cuándo usar MongoDB?

Usa MongoDB cuando...	Usa SQL cuando...
Los datos varían mucho entre registros (catálogo con atributos distintos por categoría)	La estructura es estable y bien conocida
Lees y escribes "objetos completos" (un perfil, un artículo con comentarios, un pedido)	Necesitas cruzar datos de muchas formas (reportes, ERP, contabilidad)
Prototipas rápido y el modelo cambia cada semana	La integridad referencial es crítica (finanzas, inventarios estrictos)
Registras eventos, logs o datos de sensores en volumen	Hay muchas relaciones N:M
Tu stack es JavaScript de punta a punta (MERN/MEAN)	El hosting del cliente solo ofrece MySQL
Necesitas escalar escrituras horizontalmente	El equipo domina SQL y el proyecto no tiene requisitos especiales

Ejemplos concretos:

Proyecto	Elección razonable
CMS / blog con artículos, etiquetas y comentarios	MongoDB o SQL (ambos bien)
Catálogo de marketplace con miles de tipos de producto	MongoDB (o PostgreSQL con JSONB)
Sistema de nómina o contabilidad	SQL
App de chat en tiempo real	MongoDB (mensajes) + Redis
Sistema escolar con inscripciones, grupos y calificaciones	SQL
Registro de eventos de analítica o IoT	MongoDB (o una base de series de tiempo)
Tienda en línea clásica	Cualquiera; SQL es la opción más segura

La opción híbrida

PostgreSQL con columnas JSONB (Tipos avanzados) te da flexibilidad tipo documento dentro de una base relacional. Para muchos proyectos es el mejor de ambos mundos. Elige MongoDB cuando el modelo de documentos sea realmente el centro de tu aplicación.

Ejemplo: el mismo pedido en ambos mundos

En SQL, un pedido se reconstruye uniendo cuatro tablas:

sql

SELECT pe.id, cl.nombre, pr.nombre AS producto, d.cantidad, d.precio_unitario
FROM pedidos pe
JOIN clientes cl ON cl.id = pe.cliente_id
JOIN detalle_pedido d ON d.pedido_id = pe.id
JOIN productos pr ON pr.id = d.producto_id
WHERE pe.id = 1;

En MongoDB, el pedido es un documento que ya contiene lo que necesitas mostrar:

db.pedidos.findOne({ _id: 1 })

json

{
  "_id": 1,
  "cliente": { "id": 1, "nombre": "Ana López" },
  "fecha": "2024-05-02T00:00:00Z",
  "estado": "entregado",
  "items": [
    { "productoId": 1, "nombre": "Audífonos Bluetooth", "cantidad": 1, "precio": 899 },
    { "productoId": 4, "nombre": "Libro Aprende SQL", "cantidad": 2, "precio": 349 }
  ],
  "total": 1597
}

Más simple de leer... pero si mañana el cliente cambia de nombre, ¿actualizas todos sus pedidos? (Respuesta: normalmente no, porque el pedido es un registro histórico. Este tipo de decisiones las verás en Índices y modelado.)

Ejercicios

Clasifica en qué familia NoSQL encaja cada caso: a) guardar sesiones de usuario con expiración, b) "personas que quizá conozcas", c) catálogo de productos con atributos variables, d) millones de lecturas de sensores por minuto.
Menciona dos ventajas y dos riesgos de un esquema flexible.
Para cada proyecto, ¿MongoDB o SQL? Justifica: a) sistema de facturación electrónica, b) app de recetas donde cada receta tiene ingredientes, pasos y fotos, c) sistema de reservas de hotel con disponibilidad por fecha.
Traduce los términos: tabla, fila, columna, JOIN, clave primaria.

Ver solución

a) Clave-valor (Redis, con TTL). b) Grafos. c) Documentos. d) Columnar (Cassandra) o una base de series de tiempo; MongoDB también tiene colecciones de series de tiempo.
Ventajas: agregar campos sin migraciones; registros con estructuras distintas en la misma colección. Riesgos: datos inconsistentes (tipos mezclados, campos faltantes) y errores en la app que la base no detecta.
a) SQL: datos estructurados, cálculos exactos, integridad y auditoría estricta. b) MongoDB encaja muy bien: cada receta es un documento autocontenido que se lee completo. c) SQL suele ser mejor: reglas de no traslape, transacciones y consultas por rangos de fechas sobre datos muy relacionados (PostgreSQL incluso tiene restricciones EXCLUDE para eso).
Tabla → colección, fila → documento, columna → campo, JOIN → embeber o $lookup, clave primaria → _id.

Resumen

NoSQL agrupa bases no relacionales: documentos, clave-valor, columnar y grafos.
MongoDB guarda documentos tipo JSON en colecciones; equivale a tablas y filas, pero flexibles.
Ventajas: modelo natural para JS, esquema flexible, lecturas sin JOINs, escalado horizontal.
Riesgos: integridad referencial manual, duplicación de datos, caos si no validas el esquema.
Elige según la forma de tus datos y cómo los consultas; para dudas, SQL (o PostgreSQL + JSONB) es la apuesta segura.

¿Qué es NoSQL? ​

Concepto ​

Las cuatro familias de NoSQL ​

Relacional vs documentos ​

El teorema CAP (versión corta) ​

Ventajas de MongoDB ​

Desventajas y riesgos ​

¿Cuándo usar MongoDB? ​

Ejemplo: el mismo pedido en ambos mundos ​

Ejercicios ​

Resumen ​