SQL vs NoSQL: el mismo pedido guardado de dos formas

Pedido 1042. Lucía compra dos cuadernos y cinco bolígrafos, y la tienda tiene que guardarlo en algún sitio. Dónde y con qué forma es, en el fondo, la pregunta de SQL frente a NoSQL.

En una base de datos SQL, ese pedido se reparte en varias tablas que se enlazan entre sí. En una base de documentos como MongoDB, cabe entero en un solo documento. Las dos funcionan. Esa diferencia de forma explica buena parte de todo lo demás, así que vamos a verla con el mismo pedido guardado dos veces.

Los datos del ejemplo son inventados; la teoría viene de la documentación oficial de PostgreSQL y de MongoDB.

El pedido en SQL: tres tablas que se hablan

En el modelo relacional cada cosa vive en su tabla: clientes por un lado, pedidos por otro y las líneas de cada pedido en una tercera.

CREATE TABLE clientes (id integer PRIMARY KEY, nombre text, email text);
CREATE TABLE pedidos (id integer PRIMARY KEY,
                      cliente_id integer REFERENCES clientes (id),
                      fecha date);
CREATE TABLE lineas_pedido (pedido_id integer REFERENCES pedidos (id),
                            producto text, cantidad integer);

CREATE TABLE clientes (id integer PRIMARY KEY, nombre text, email text);
CREATE TABLE pedidos (id integer PRIMARY KEY,
                      cliente_id integer REFERENCES clientes (id),
                      fecha date);
CREATE TABLE lineas_pedido (pedido_id integer REFERENCES pedidos (id),
                            producto text, cantidad integer);

CREATE TABLE clientes (id integer PRIMARY KEY, nombre text, email text);
CREATE TABLE pedidos (id integer PRIMARY KEY,
                      cliente_id integer REFERENCES clientes (id),
                      fecha date);
CREATE TABLE lineas_pedido (pedido_id integer REFERENCES pedidos (id),
                            producto text, cantidad integer);

Para ver el pedido completo, unes las tablas con una consulta:

SELECT c.nombre, l.producto, l.cantidad
FROM pedidos p
JOIN clientes c ON c.id = p.cliente_id
JOIN lineas_pedido l ON l.pedido_id = p.id
WHERE p.id = 1042;

SELECT c.nombre, l.producto, l.cantidad
FROM pedidos p
JOIN clientes c ON c.id = p.cliente_id
JOIN lineas_pedido l ON l.pedido_id = p.id
WHERE p.id = 1042;

SELECT c.nombre, l.producto, l.cantidad
FROM pedidos p
JOIN clientes c ON c.id = p.cliente_id
JOIN lineas_pedido l ON l.pedido_id = p.id
WHERE p.id = 1042;

Dos cosas buenas de este reparto. La primera es que el cliente se guarda una sola vez, aunque haga cien pedidos. La segunda es que las tablas se vigilan entre sí: según la documentación de PostgreSQL, una clave foránea (REFERENCES) exige que los valores de una columna coincidan con los de otra tabla, y eso mantiene la integridad referencial (PostgreSQL, «Constraints», consultado el 21-10-2026). Si intentas crear un pedido de un cliente que no existe, la base lo rechaza.

Las transacciones completan el cuadro: agrupan varios pasos en una operación de todo o nada, de modo que si algo falla a medias, ninguno de los pasos queda aplicado (PostgreSQL, «Transactions», consultado el 21-10-2026).

El mismo pedido en MongoDB: un documento

En MongoDB el pedido es un documento con campos y valores, y un valor puede ser a su vez otro documento o una lista.

{
  "_id": 1042,
  "cliente": { "nombre": "Lucía", "email": "lucia@example.com" },
  "fecha": "2026-10-22",
  "lineas": [
    { "producto": "Cuaderno", "cantidad": 2 },
    { "producto": "Bolígrafo", "cantidad": 5 }
  ]
}

{
  "_id": 1042,
  "cliente": { "nombre": "Lucía", "email": "lucia@example.com" },
  "fecha": "2026-10-22",
  "lineas": [
    { "producto": "Cuaderno", "cantidad": 2 },
    { "producto": "Bolígrafo", "cantidad": 5 }
  ]
}

{
  "_id": 1042,
  "cliente": { "nombre": "Lucía", "email": "lucia@example.com" },
  "fecha": "2026-10-22",
  "lineas": [
    { "producto": "Cuaderno", "cantidad": 2 },
    { "producto": "Bolígrafo", "cantidad": 5 }
  ]
}

Para recuperarlo no hay que unir nada:

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

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

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

La guía de modelado de MongoDB lo resume en una idea: los datos que se consultan juntos se guardan juntos, y el modelo se diseña según cómo los usa la aplicación (MongoDB Manual, «Data Modeling», consultado el 21-10-2026). Otra consecuencia práctica: en una misma colección, los documentos no tienen por qué compartir los mismos campos. El propio manual pone el ejemplo de un catálogo donde cada producto tiene atributos distintos y aun así todos conviven en una colección.

Lo que cambia, lado a lado

La última fila sale de Microsoft Learn («Descripción de los modelos de datos», consultado el 21-10-2026). Las filas de estructura, relaciones y transacciones, de los manuales de PostgreSQL y MongoDB. En la de transacciones, MongoDB aclara que, al poder embeber datos, muchos casos prácticos no necesitan transacciones entre varios documentos, y que cuando hacen falta las soporta (MongoDB Manual, «Transactions»).

De «cuál es más rápido» no hablamos a propósito: ninguna de las fuentes consultadas sostiene que una gane a la otra en general. MongoDB, por ejemplo, plantea el rendimiento como una cuestión de diseñar el modelo según los patrones de acceso de tu aplicación.

«NoSQL» es un cajón con varias cosas dentro

Microsoft Learn agrupa los almacenes no relacionales en varias familias: documento, clave-valor, familia de columnas y grafo. MongoDB es un ejemplo de la primera. Las otras resuelven problemas distintos, y por eso casi nunca tiene sentido comparar «SQL» con «NoSQL» a secas.

Si quieres ver motores concretos, en el blog tienes Redis y su uso para acelerar la carga, el modelado de datos en Cassandra y Amazon DynamoDB. Del lado relacional, MariaDB y SQLAlchemy para acceder a bases SQL desde Python.

Las dos orillas se acercan

Elegir bando es menos definitivo de lo que parece. PostgreSQL, una base relacional, ofrece los tipos json y jsonb para guardar datos JSON, y jsonb admite indexación (PostgreSQL, «JSON Types», consultado el 21-10-2026). Es decir, puedes tener tablas y, dentro de una columna, documentos. Y MongoDB, como acabas de ver, tiene transacciones.

Por eso la pregunta útil rara vez es «¿cuál es mejor?». Es «¿qué forma tienen mis datos y cómo voy a consultarlos?». Si hay muchas relaciones entre entidades y necesitas que todo cuadre, las tablas encajan muy bien. Si trabajas con objetos que se leen enteros de una vez, un documento también.

Pruébalo esta tarde

Con una tarde tienes las dos versiones funcionando:

1. Crea las tres tablas de arriba en PostgreSQL o en cualquier base SQL, inserta el pedido y lanza la consulta con JOIN.

2. Intenta insertar un pedido de un cliente que no existe y lee el error. Es la base de datos cuidando de tu información.

3. Guarda el documento en MongoDB y recupéralo por su _id.

4. Añade un campo nuevo, por ejemplo una nota de regalo, solo al pedido 1042. Fíjate en lo que haces en cada modelo.

Cuando lo hayas hecho una vez, la diferencia deja de ser teoría.

¿Quieres verlo dentro de una app completa?

Descarga el dossier de Rock the AI Code y consulta los 8 proyectos del programa, entre ellos uno con SQL y otro con MongoDB.

Descargar el dossier →

Cuando quieres verlo dentro de una aplicación completa

Probar una tabla suelta es un buen primer paso. Verla trabajar dentro de un producto, con un servidor delante y usuarios que guardan cosas, es otro nivel. Rock the AI Code, el máster de la Tech School de ThePower, lo plantea así. Los textos siguientes son literales de su ficha, consultada el 21-10-2026.

• Proyecto 04, «App de notas»: «Modela datos en SQL, conecta un backend y edita tus notas mediante una arquitectura cliente-servidor».

• Proyecto 05, «Suscripción de pago»: «Implementa autenticación, pagos recurrentes y persistencia NoSQL con MongoDB para un producto SaaS».

• Entre las capacidades al terminar: «Desarrollar el backend: servidor con Node.js y Express, y bases de datos relacionales con SQL y PostgreSQL».

• Son «8 proyectos reales entregables de dificultad progresiva: desde una landing page hasta un SaaS completo».

• Y la ficha dice: «No necesitas conocimientos previos».

Dicho de otro modo: en el programa construyes una app con SQL y otra con MongoDB, así que ves cada modelo funcionando en un producto. Puedes mirar la ficha de Rock the AI Code completa o pedir el dossier.

Tu siguiente paso: ver SQL y MongoDB en un producto real

Pide el dossier de Rock the AI Code y revisa el temario completo y los proyectos.

Descargar el dossier →

Si tu camino va más por el análisis de datos, el Máster en AI Data Analytics incluye en su temario un «Módulo 8 SQL», marcado como opcional en la ficha. Y si todavía estás decidiendo por dónde empezar con el código del servidor, qué es el desarrollo backend y cómo empezar te da el mapa general.

Preguntas frecuentes sobre SQL y NoSQL

¿MongoDB es SQL o NoSQL?

NoSQL. Es una base de datos de documentos: guarda los registros como documentos BSON, una representación binaria de JSON con más tipos de datos (MongoDB Manual, «Documents»).

¿Es más rápido SQL o NoSQL?

Ninguna lo es por defecto. La documentación de MongoDB recomienda diseñar el modelo según los patrones de acceso de tu aplicación para optimizar el rendimiento, y una buena costumbre en cualquier base es medir con tus propias consultas.

¿Es difícil aprender SQL?

Está al alcance de quien practique con constancia. En este artículo ya has visto la idea central, tablas enlazadas y una consulta que las une, y a partir de ahí cada ejemplo nuevo añade una pieza.

¿Puedo aprender bases de datos sin saber programar?

Sí. La ficha de Rock the AI Code dice: «No necesitas conocimientos previos» (consultado el 21-10-2026).

¿Se pueden usar SQL y NoSQL en el mismo proyecto?

Sí. Nada impide usar cada una donde mejor encaje, y PostgreSQL permite incluso guardar JSON dentro de una tabla. En la ficha de Rock the AI Code, el Proyecto 04 modela datos en SQL y el Proyecto 05 usa persistencia NoSQL con MongoDB.