NoSQL: bases de datos no relacionales

Todo el curso ha girado en torno a bases de datos relacionales: tablas, filas, columnas y relaciones entre ellas con SQL. Pero no son la única forma de guardar datos. Existe todo un mundo de bases de datos NoSQL que resuelven problemas distintos con ideas distintas. En esta lección entenderás qué son, en qué se diferencian y cuándo elegir cada una.

¿Qué significa “NoSQL”?

El nombre confunde. NoSQL no significa “sin SQL” ni “SQL es malo”. Hoy se interpreta como “Not Only SQL” (no solo SQL): un conjunto de bases de datos que no siguen el modelo relacional de tablas.

De hecho, muchas bases NoSQL modernas ofrecen lenguajes de consulta parecidos a SQL. La diferencia no está en el lenguaje, sino en cómo se organizan los datos por dentro.

El cambio de mentalidad: tablas vs documentos

En el modelo relacional, un dato se reparte entre varias tablas para no repetir información (lo que llamamos normalización). Para reconstruirlo, usas JOIN.

En una base de datos de documentos, ese mismo dato vive junto, en un solo documento anidado. Míralo con un ejemplo: una usuaria y sus pedidos.

{
  "_id": 1,
  "name": "Ana",
  "orders": [
    { "id": 10, "total": 59.99 }
  ]
}

Cada enfoque tiene su lógica:

• Relacional: cada cosa se guarda una sola vez. Es limpio, evita datos duplicados y garantiza la coherencia. El precio es que reconstruir la información completa requiere unir tablas.
• Documento: todo lo que sueles leer junto se guarda junto. Leerlo es una sola operación, sin JOIN. El precio es que un mismo dato puede acabar repetido en varios documentos, y mantenerlo coherente es tu responsabilidad.

Diferencias clave con SQL

Esquema rígido vs flexible

En SQL, si una tabla users tiene las columnas id y name, todas las filas tienen exactamente esas columnas. Añadir un campo nuevo requiere un ALTER TABLE.

En una base de documentos, dos registros de la misma colección pueden ser distintos:

// En la misma colección "users" pueden convivir:
{ "_id": 1, "name": "Ana" }
{ "_id": 2, "name": "Bea", "email": "bea@web.dev", "premium": true }

Esta flexibilidad es cómoda cuando los datos evolucionan rápido, pero también quita la red de seguridad que te da un esquema estricto.

ACID vs BASE

Recuerda ACID de la lección de transacciones: garantías fuertes de que los datos siempre son coherentes. Muchas bases NoSQL priorizan la disponibilidad y la escala sobre esa consistencia inmediata, siguiendo el modelo BASE (Basically Available, Soft state, Eventual consistency): un cambio puede tardar un instante en verse reflejado en todos los servidores.

No es que una sea mejor: es un compromiso. Un banco quiere ACID; un contador de “me gusta” de una red social puede permitirse consistencia eventual a cambio de aguantar millones de escrituras.

Escalado: vertical vs horizontal

Es una de las razones por las que nació NoSQL. Cuando una base se queda pequeña, tienes dos caminos:

• Vertical (scale up): poner un servidor más potente. Simple, pero tiene un techo físico y económico. Es el enfoque tradicional de las bases SQL.
• Horizontal (scale out): repartir los datos entre muchos servidores más modestos. No tiene techo, pero es más complejo de coordinar. Muchas bases NoSQL nacieron precisamente para hacer esto fácil.

Los cuatro tipos de bases NoSQL

“NoSQL” no es una sola cosa: engloba familias muy diferentes. Estas son las cuatro principales.

1. Documento

Guardan documentos parecidos a JSON. Es el tipo más popular y el más cercano a lo que ya conoces. Ejemplos: MongoDB, CouchDB.

2. Clave-valor

Un gran diccionario: pides un valor por su clave y lo obtienes al instante. Súper rápidas, ideales para caché y sesiones. Ejemplos: Redis, DynamoDB.

3. Columnar (familias de columnas)

Optimizadas para escribir y leer cantidades enormes de datos distribuidos en muchos servidores. Ejemplos: Cassandra, HBase.

4. Grafo

Modelan nodos y las relaciones entre ellos. Perfectas para redes sociales, recomendaciones o detección de fraude, donde lo importante son las conexiones. Ejemplos: Neo4j, ArangoDB.

Un ejemplo con Node.js: MongoDB

Veamos NoSQL en acción. MongoDB es la base de documentos más usada. En Node se conecta con el paquete oficial mongodb:

npm install mongodb

Fíjate en cómo no hay CREATE TABLE: insertas un objeto y la colección se crea sola.

import { MongoClient } from "mongodb"

const client = new MongoClient("mongodb://localhost:27017")
await client.connect()

const db = client.db("tienda")
const products = db.collection("products")

// Insertar un documento (no hace falta definir columnas antes)
await products.insertOne({
  name: "Teclado mecánico",
  price: 79.99,
  tags: ["periféricos", "gaming"], // ¡un array dentro del documento!
})

// Consultar: "productos con precio menor que 100"
const baratos = await products
  .find({ price: { $lt: 100 } })
  .toArray()

console.log(baratos)

await client.close()

Compara mentalmente las dos formas de pedir lo mismo:

-- En SQL (relacional)
SELECT * FROM products WHERE price < 100;

// En MongoDB (documento)
products.find({ price: { $lt: 100 } })

Misma idea, sintaxis muy distinta. Lo que no cambia es la forma de pensar en los datos que has entrenado en el curso: filtrar, ordenar, agrupar.

Otro ejemplo: Redis (clave-valor)

Redis es el ejemplo perfecto de clave-valor. Se usa muchísimo como caché delante de una base de datos SQL para acelerar lecturas repetidas:

import { createClient } from "redis"

const redis = createClient()
await redis.connect()

// Guardar un valor bajo una clave, que caduca en 60 segundos
await redis.set("user:1:name", "Ana", { EX: 60 })

// Recuperarlo al instante
const name = await redis.get("user:1:name") // "Ana"

Entonces, ¿SQL o NoSQL?

No es una guerra: conviven. Muchísimos proyectos reales usan PostgreSQL o MySQL para los datos principales y Redis para la caché, o MongoDB para una parte concreta. Se llama persistencia políglota.

Esta guía rápida te ayuda a decidir:

Consejo: para la mayoría de proyectos, empezar con una base relacional (como PostgreSQL) es la opción más segura y versátil. Añade NoSQL cuando tengas un problema concreto que resuelva mejor, no por moda.

En resumen

• NoSQL significa “Not Only SQL”: bases de datos que no usan el modelo relacional de tablas.
• El gran cambio es guardar los datos juntos (documentos anidados) en lugar de repartidos en tablas unidas por JOIN.
• Ofrecen esquema flexible y están diseñadas para escalar horizontalmente, a menudo cambiando consistencia fuerte (ACID) por disponibilidad (BASE).
• Hay cuatro familias principales: documento (MongoDB), clave-valor (Redis), columnar (Cassandra) y grafo (Neo4j).
• SQL y NoSQL no compiten: se combinan. Empieza por lo relacional y suma NoSQL cuando un problema concreto lo pida.