SQL o NoSQL: qué base de datos elegir

"SQL o NoSQL" parece una elección entre dos productos, pero no lo es. SQL es un lenguaje de consulta y, por extensión, el modelo relacional que está detrás. NoSQL es un paraguas para todo lo que no sigue ese modelo: bases de documentos, clave-valor, columnares y de grafos. Compararlos es comparar formas de organizar datos.

La decisión importa porque cambiar de base después sale caro: reescribes consultas, migras datos y rehaces pruebas. Por eso conviene elegir según la forma de tus datos y cómo accedes a ellos, no por moda.

¿Qué es una base de datos SQL?#

Una base SQL (relacional) guarda datos en tablas de filas y columnas. Defines el esquema antes: nombres de columnas, tipos y restricciones. Las tablas se enlazan con claves foráneas, y la consulta las cruza con JOIN.

Ejemplos comunes son PostgreSQL, MySQL y SQLite. La promesa central es la integridad: la base rechaza un pedido que apunte a un usuario inexistente, y una transacción garantiza que un conjunto de escrituras ocurre completo o no ocurre.

¿Qué es una base de datos NoSQL?#

"NoSQL" no describe un modelo, describe una ausencia. Los tipos más usados por quien hospeda bots, APIs y sitios web son:

• Documentos (MongoDB): objetos parecidos a JSON, agrupados en colecciones. Cada documento puede llevar listas y objetos anidados.
• Clave-valor y estructuras en memoria (Redis): acceso por clave, con tipos como strings, hashes, listas, sets y sorted sets, según la documentación de Redis.
• Columnares y de grafos: para análisis a gran escala y redes de relaciones. Quedan fuera del alcance de la mayoría de los proyectos pequeños.

Lo que une a estas bases es la decisión de renunciar a parte del modelo relacional a cambio de otra ventaja: formato flexible, acceso directo por clave o facilidad para repartir datos entre servidores.

¿Cuál es la diferencia entre SQL y NoSQL, lado a lado?#

La tabla es una tendencia, no una ley. PostgreSQL guarda JSON con el tipo jsonb, y MongoDB tiene transacciones y validación de esquema. Las fronteras se mezclan, por eso el criterio correcto es tu patrón de acceso, no la etiqueta.

¿Cómo queda el mismo dato en cada modelo?#

Piensa en un pedido con ítems. En el modelo relacional, se divide en tablas:

CREATE TABLE pedidos (
  id         serial PRIMARY KEY,
  usuario_id integer NOT NULL,
  creado_en  timestamptz NOT NULL DEFAULT now()
);

CREATE TABLE items_pedido (
  pedido_id  integer NOT NULL REFERENCES pedidos (id),
  producto   text NOT NULL,
  cantidad   integer NOT NULL CHECK (cantidad > 0),
  PRIMARY KEY (pedido_id, producto)
);

SELECT p.id, i.producto, i.cantidad
FROM pedidos p
JOIN items_pedido i ON i.pedido_id = p.id
WHERE p.usuario_id = 42;

En el modelo de documentos, el mismo pedido se vuelve un solo objeto, con los ítems dentro (ejemplo en mongosh):

db.pedidos.insertOne({
  usuarioId: 42,
  creadoEn: new Date(),
  items: [
    { producto: "Camiseta", cantidad: 2 },
    { producto: "Taza", cantidad: 1 },
  ],
});

db.pedidos.find({ usuarioId: 42 });

Leer el pedido completo es una sola operación, sin unión. El costo aparece cuando el mismo dato se consulta desde otro ángulo, por ejemplo "qué pedidos contienen una Taza": en el modelo relacional eso es un índice y un JOIN, y en el modelo de documentos dependes de un índice sobre el campo anidado y de mantener los datos consistentes en la aplicación.

¿Cuándo son las transacciones las que deciden?#

Una transferencia de saldo entre dos cuentas tiene que ocurrir completa o no ocurrir. En SQL esto es natural:

BEGIN;
UPDATE cuentas SET saldo = saldo - 100 WHERE id = 1;
UPDATE cuentas SET saldo = saldo + 100 WHERE id = 2;
COMMIT;

En PostgreSQL, el nivel de aislamiento por defecto es Read Committed, y puedes subirlo a Repeatable Read o Serializable cuando la lógica lo exija, según la documentación.

MongoDB soporta transacciones entre varios documentos, pero su documentación advierte que suelen costar más que las escrituras en un solo documento y recomienda incrustar los datos como primera opción de modelado.

La regla práctica: si tu dominio vive de transacciones entre muchas entidades (saldos, inventario, pagos), el modelo relacional es el ajuste natural. Si cada operación toca un solo objeto, el modelo de documentos funciona bien.

Y el esquema flexible, ¿es ventaja o riesgo?#

En una base de documentos, la colección acepta documentos con campos distintos. Eso acelera el inicio del proyecto y ayuda con datos heterogéneos, como catálogos donde cada producto tiene atributos propios. La documentación de MongoDB describe ese modelo flexible y la validación de esquema para cuando quieras fijar el formato.

El riesgo es el esquema implícito: sin reglas, cada versión del código escribe de una manera y la lectura tiene que tratar todas las variaciones. En una base relacional, la migración da más trabajo, pero la base garantiza que todo registro respeta la estructura. Existe un punto medio: PostgreSQL combina columnas fijas con un campo jsonb indexable, lo que cubre muchos casos "medio flexibles" sin cambiar de base.

¿Cómo elegir entre SQL y NoSQL?#

Hazte cuatro preguntas:

1. ¿Tus datos tienen relaciones fuertes entre sí? Usuarios, pedidos, suscripciones e inventario apuntan unos a otros. SQL.
2. ¿Lees y escribes el objeto entero de una vez? Configuración por servidor de Discord, perfil con campos opcionales. Los documentos funcionan bien, y PostgreSQL con jsonb también.
3. ¿El acceso es por clave y perder el dato es tolerable? Caché, sesión, cooldown, rate limit. Redis. Puede escribir en disco (mira la documentación de persistencia), pero fue pensado para datos que caben en memoria.
4. ¿El formato cambia cada semana? En un prototipo, la flexibilidad ayuda. En producción, evalúa cuánto vale imponer estructura.

Sin una razón clara para lo contrario, una base relacional es el punto de partida más seguro. Para decidir dentro de cada familia, mira qué base de datos elegir, PostgreSQL o MySQL y qué es MongoDB. Para el papel de Redis junto a otra base, lee Redis como caché o como base de datos.

Cómo hacerlo en Square Cloud#

Square Cloud ofrece hosting de MongoDB, PostgreSQL, MySQL y Redis, a partir del plan Standard. El plan Hobby no incluye hosting de bases de datos. Así tienes los dos lados de la comparación: SQL con PostgreSQL o MySQL, NoSQL con MongoDB o Redis.

Creas la base en el panel y queda lista en segundos en el mismo datacenter que tus aplicaciones, con una latencia media de cerca de 1 ms y TLS obligatorio. Combinar dos motores en el mismo proyecto, como PostgreSQL para los datos permanentes y Redis para caché, solo requiere crear los dos y guardar las URLs de conexión en variables de entorno. La cantidad de bases solo está limitada por la RAM del plan: cada una usa como mínimo 512 MB (Redis) o 1024 MB (las demás).

Puedes tomar snapshots manuales cuando quieras, y todo plan que incluye bases de datos tiene también un snapshot automático diario. Puedes restaurar un snapshot en la misma base, en otra del mismo motor o en una base nueva. Redis tiene persistencia, y PostgreSQL es el nativo, sin extensiones. Mira las opciones en Bases de datos.