Bases de Datos Relacionales y No Relacionales: la Guía Definitiva

"¿Debo usar SQL o NoSQL?" es la pregunta equivocada. La correcta es: ¿qué forma tienen mis datos y qué garantías necesito tener sobre ellos? Responde a eso y la elección de la base de datos aparece sola.

Esta guía muestra los dos mundos lado a lado — misma aplicación, modelados distintos — con los comandos de cada uno.

Índice

• 1 · Qué es una base de datos relacional
• 2 · Qué es una base de datos no relacional
• 3 · Los cinco tipos de NoSQL
• 4 · El mismo sistema modelado de las dos formas
• 5 · ACID, BASE y el teorema CAP
• 6 · Cómo se consulta en cada una
• 7 · Escala: vertical, horizontal y sharding
• 8 · Cuándo usar cada una
• 9 · Errores comunes de ambos lados
• 10 · Persistencia políglota

1. Qué es una base de datos relacional

Una base de datos relacional guarda los datos en tablas — filas y columnas con tipos definidos —, y las relaciones entre ellas están declaradas y garantizadas por la propia base de datos.

Tres ideas lo sostienen todo:

1. Esquema definido: declaras de antemano qué columnas existen y de qué tipo son. La base rechaza lo que no encaja.
2. Normalización: cada hecho se guarda una sola vez. La dirección del cliente está en la tabla de clientes, no repetida en cada pedido.
3. Integridad referencial: una clave foránea impide que exista un pedido de un cliente que no existe.

CREATE TABLE clientes (
  id BIGSERIAL PRIMARY KEY,
  nome VARCHAR(120) NOT NULL,
  email VARCHAR(200) UNIQUE NOT NULL
);

CREATE TABLE pedidos (
  id BIGSERIAL PRIMARY KEY,
  cliente_id BIGINT NOT NULL REFERENCES clientes (id),
  total DECIMAL(12,2) NOT NULL CHECK (total >= 0),
  criado_em TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
);

Fíjate en lo que ese fragmento ya garantiza, sin una línea de código de aplicación: el correo no se repite, el total nunca es negativo y ningún pedido apunta a un cliente inexistente. Esa es la propuesta de valor del modelo relacional: la regla vive en el dato, no en quien escribe sobre él.

Nombres principales: PostgreSQL, MySQL, SQL Server, Oracle, Firebird, SQLite, MariaDB, DB2.

2. Qué es una base de datos no relacional

"NoSQL" nunca quiso decir "sin SQL" — hoy se lee como Not Only SQL. Es un paraguas para bases de datos que renunciaron a parte del modelo relacional para ganar otra cosa: escala horizontal, flexibilidad de esquema o rendimiento en un patrón de acceso concreto.

Lo que suele cambiar:

• Esquema flexible: cada documento puede tener campos distintos. Bueno para datos heterogéneos, malo para la consistencia sin disciplina.
• Desnormalización intencionada: el dato que se lee junto se guarda junto. Una lectura, sin JOIN.
• Integridad en la aplicación: la base no garantiza que el cliente_id exista — quien lo garantiza es tu código.

// MongoDB: el pedido lleva consigo lo que necesita
db.pedidos.insertOne({
  _id: ObjectId(),
  cliente: { id: 42, nome: "Ana Souza", email: "ana@email.com" },
  itens: [
    { produto: "Teclado", qtd: 1, preco: 199.9 },
    { produto: "Mouse",   qtd: 2, preco:  89.9 }
  ],
  total: 379.7,
  criadoEm: new Date()
});

Una lectura trae el pedido entero, listo para la pantalla. El precio de eso: si Ana cambia de correo, ese documento sigue con el antiguo — y tienes que decidir si eso es un bug o exactamente lo que querías (una foto histórica del pedido).

3. Los cinco tipos de NoSQL

Tratar "NoSQL" como una única categoría es el error más común. Son familias con propósitos muy distintos.

Documento

db.produtos.find({ categoria: "games", preco: { $lt: 500 } })
          .sort({ preco: -1 })
          .limit(10);

Clave-valor

SET sessao:abc123 '{"userId":42}' EX 3600   # expira en 1 hora
GET sessao:abc123
INCR contador:visitas:2026-08-10

Columnar

-- Cassandra (CQL): el modelado nace de la consulta, no del dominio
CREATE TABLE eventos_por_usuario (
  usuario_id UUID,
  quando TIMESTAMP,
  tipo TEXT,
  PRIMARY KEY (usuario_id, quando)
) WITH CLUSTERING ORDER BY (quando DESC);

Grafo

// Neo4j (Cypher): "amigos de amigos a los que les gusta lo que a mí me gusta"
MATCH (eu:Pessoa {id: 42})-[:AMIGO*2]-(sugestao:Pessoa)
WHERE NOT (eu)-[:AMIGO]-(sugestao)
RETURN sugestao.nome, COUNT(*) AS forca
ORDER BY forca DESC LIMIT 10;

Este es el caso en que NoSQL gana de forma indiscutible: la misma pregunta en SQL exigiría JOINs recursivos y sería mucho más lenta a medida que crece la profundidad.

Vectorial

-- pgvector: búsqueda semántica dentro del propio PostgreSQL
SELECT titulo, embedding <-> $1 AS distancia
FROM documentos ORDER BY distancia LIMIT 5;

4. El mismo sistema modelado de las dos formas

Un blog con posts, autores y comentarios.

Relacional — tres tablas, cada hecho una vez:

CREATE TABLE autores (
  id BIGSERIAL PRIMARY KEY,
  nome VARCHAR(120) NOT NULL,
  email VARCHAR(200) UNIQUE NOT NULL
);

CREATE TABLE posts (
  id BIGSERIAL PRIMARY KEY,
  autor_id BIGINT NOT NULL REFERENCES autores (id),
  titulo VARCHAR(200) NOT NULL,
  corpo TEXT NOT NULL,
  publicado_em TIMESTAMP
);

CREATE TABLE comentarios (
  id BIGSERIAL PRIMARY KEY,
  post_id BIGINT NOT NULL REFERENCES posts (id) ON DELETE CASCADE,
  autor_nome VARCHAR(120) NOT NULL,
  texto TEXT NOT NULL,
  criado_em TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
);

-- La pantalla del post: un JOIN
SELECT p.titulo, p.corpo, a.nome AS autor
FROM posts p JOIN autores a ON a.id = p.autor_id
WHERE p.id = 1;

Documento — el post lleva lo que la pantalla necesita:

db.posts.insertOne({
  _id: 1,
  titulo: "Bancos relacionais e não relacionais",
  corpo: "...",
  autor: { id: 7, nome: "Jhonatan Pinheiro" },   // desnormalizado
  comentarios: [                                  // anidado
    { autorNome: "Ana", texto: "Ótimo post!", criadoEm: new Date() }
  ],
  publicadoEm: new Date()
});

// La pantalla del post: una lectura, sin JOIN
db.posts.findOne({ _id: 1 });

El trade-off aparece a la hora de cambiar algo: renombrar al autor es un UPDATE en una fila en el relacional, y un updateMany en todos sus documentos en NoSQL. En cambio, leer la página es una única búsqueda en el documento — y un JOIN en el relacional.

Anidar los comentarios dentro del post funciona bien hasta el post viral con 50 mil comentarios. Un documento tiene límite de tamaño (16 MB en MongoDB) y crece con cada escritura. Una colección aparte vuelve a ser la respuesta.

5. ACID, BASE y el teorema CAP

ACID es el contrato de las bases relacionales:

• Atomicidad — todo o nada.
• Consistencia — restricciones siempre válidas.
• Aislamiento — las transacciones concurrentes no se estorban.
• Durabilidad — si hizo commit, está grabado.

BEGIN;
UPDATE contas SET saldo = saldo - 100 WHERE id = 1;
UPDATE contas SET saldo = saldo + 100 WHERE id = 2;
COMMIT;   -- o no ocurre nada

BASE es la postura de buena parte del NoSQL distribuido: Basically Available, Soft state, Eventually consistent. El sistema acepta quedar temporalmente incoherente entre réplicas a cambio de disponibilidad y escala.

El teorema CAP explica por qué: un sistema distribuido sujeto a una partición de red debe elegir entre consistencia y disponibilidad. No es una elección filosófica — es lo que ocurre cuando cae el cable entre dos centros de datos.

Conviene corregir dos mitos comunes: NoSQL no es sinónimo de "sin transacciones" (MongoDB tiene transacciones multidocumento desde la 4.0) y relacional no es sinónimo de "no escala" (existe PostgreSQL con decenas de terabytes en producción).

6. Cómo se consulta en cada una

La misma pregunta — "los 10 productos de games más caros por debajo de 500" — en cada lenguaje:

-- SQL
SELECT nome, preco FROM produtos
WHERE categoria = 'games' AND preco < 500
ORDER BY preco DESC LIMIT 10;

// MongoDB
db.produtos.find(
  { categoria: "games", preco: { $lt: 500 } },
  { nome: 1, preco: 1 }
).sort({ preco: -1 }).limit(10);

-- Cassandra (CQL): solo filtra por lo que está en la clave; el resto exige otra tabla
SELECT nome, preco FROM produtos_por_categoria
WHERE categoria = 'games' LIMIT 10;

// Neo4j
MATCH (p:Produto {categoria: 'games'})
WHERE p.preco < 500
RETURN p.nome, p.preco ORDER BY p.preco DESC LIMIT 10;

Y la agregación — facturación por mes:

-- SQL
SELECT DATE_TRUNC('month', criado_em) AS mes, SUM(total) AS faturamento
FROM pedidos GROUP BY 1 ORDER BY 1;

// MongoDB — aggregation pipeline
db.pedidos.aggregate([
  { $group: {
      _id: { $dateTrunc: { date: "$criadoEm", unit: "month" } },
      faturamento: { $sum: "$total" }
  } },
  { $sort: { _id: 1 } }
]);

La diferencia de fondo: SQL es declarativo y está estandarizado — lo aprendes una vez y lo llevas a cualquier base relacional. Cada NoSQL tiene su propio lenguaje, y cambiar de base suele significar reescribir la capa de datos.

7. Escala: vertical, horizontal y sharding

• Vertical (agrandar la máquina): simple, funciona mucho más lejos de lo que se dice por ahí, y un día se acaba.
• Horizontal (sumar máquinas): escala indefinidamente, y trae consistencia distribuida, rebalanceo y una operación más compleja.

Las bases relacionales escalan la lectura con naturalidad mediante réplicas:

-- PostgreSQL: la réplica de lectura recibe los informes
SELECT pg_is_in_recovery();   -- true = es una réplica

La escritura es el punto difícil: solo un primario acepta escrituras. Las salidas son el particionado, el sharding en la aplicación o extensiones como Citus.

-- Particionado nativo: una partición por mes
CREATE TABLE eventos (id BIGSERIAL, criado_em DATE NOT NULL, dados JSONB)
PARTITION BY RANGE (criado_em);

CREATE TABLE eventos_2026_08 PARTITION OF eventos
FOR VALUES FROM ('2026-08-01') TO ('2026-09-01');

En las bases distribuidas, el sharding es una premisa de diseño:

// MongoDB: la shard key define la distribución — y es casi imposible de cambiar después
sh.shardCollection("loja.pedidos", { clienteId: "hashed" });

La elección de la clave de shard es la decisión más cara de una base distribuida. Una clave mala genera una hot partition: un nodo con el 90% del tráfico y el resto del clúster ocioso.

8. Cuándo usar cada una

Usa relacional cuando (y este es el valor por defecto para la mayoría de los sistemas):

• Los datos tienen relaciones y vas a consultarlos de formas que todavía no imaginas.
• Hay dinero, inventario, matrículas o cualquier cosa que no puede divergir.
• Necesitas informes ad hoc y el equipo de datos habla SQL.
• La consistencia fuerte es un requisito, no un deseo.

Usa documento cuando:

• El formato varía legítimamente por registro (un catálogo con atributos distintos por categoría).
• El agregado se lee y se escribe entero, casi siempre por la misma clave.
• El esquema cambia con mucha frecuencia al principio del producto.

Usa clave-valor cuando:

• Necesitas latencia de milisegundos por clave: caché, sesión, rate limit, cola, ranking.

Usa columnar cuando:

• La escritura es masiva y continua, y se consulta por rango de tiempo: telemetría, IoT, logs, eventos.

Usa grafo cuando:

• La pregunta es sobre el camino entre entidades: red social, recomendación, fraude, dependencias.

Usa vectorial cuando:

• La búsqueda es por significado, no por igualdad: RAG, similitud semántica, recomendación por contenido.

Un resumen práctico:

9. Errores comunes de ambos lados

Del lado NoSQL:

1. Elegir por moda. "Es más moderno" no es un requisito técnico. La pregunta es qué problema de tu sistema no resuelve el modelo relacional.
2. Creer que "sin esquema" es "sin modelado". El esquema no desapareció: salió de la base y se fue al código, repartido por varios sitios — muchas veces de forma inconsistente.
3. Usar documentos para datos altamente relacionales. Si estás simulando un JOIN en la aplicación, se eligió la base equivocada.
4. Ignorar la clave de acceso. En Cassandra y DynamoDB, quien no modela a partir de la consulta descubre demasiado tarde que la consulta necesaria es imposible.
5. Confiar en la consistencia eventual sin entender el efecto. "Lo escribí y no apareció en la pantalla" se convierte en un ticket de soporte cada día.

Del lado relacional:

1. Normalizar hasta la parálisis. Siete JOINs para montar una pantalla sencilla es señal de que faltó una vista materializada o algo de desnormalización consciente.
2. Guardarlo todo en JSONB y llamarlo flexible. Si filtras por ese campo en cada informe, merece ser una columna con índice.
3. No indexar la clave foránea. La base crea un índice en la PK, no siempre en la FK — y el JOIN paga el precio.
4. Usar la base de datos como cola. Funciona hasta cierto volumen; después aparecen los bloqueos y el bloat. Hay herramientas específicas para eso.
5. Dar por hecho que no escala sin intentarlo. Un buen modelado, el índice correcto y una réplica llegan más lejos de lo que la mayoría de los proyectos va a necesitar.

10. Persistencia políglota

Los sistemas maduros rara vez usan una sola base de datos. Una arquitectura habitual de e-commerce:

El coste de ese diseño es real: más piezas que operar, monitorizar, versionar y mantener sincronizadas. Empieza con una base relacional bien modelada y añade una pieza especializada cuando aparezca un cuello de botella concreto — nunca por anticipación.

Conclusión

Relacional y no relacional no compiten: resuelven problemas distintos.

• El modelo relacional sigue siendo el valor por defecto correcto para la mayoría de los sistemas. Se equivoca a favor de la corrección: si el dato no cuadra, lo rechaza.
• NoSQL es la respuesta correcta cuando el patrón de acceso es conocido y específico, o cuando la escala horizontal es un requisito real.
• El PostgreSQL moderno hace JSONB, búsqueda textual, vectores y series temporales. Antes de traer una base nueva a la arquitectura, conviene comprobar si la que ya usas no lo resuelve.

La pregunta final nunca es "cuál es la mejor base de datos". Es "qué garantías necesito y qué precio estoy dispuesto a pagar por ellas".