Software Architecture
Compara SQL y NoSQL según modelo, consultas, transacciones, consistencia, escalado, operación y evolución, evitando elegir por etiquetas generales.
La elección de una base de datos no se resuelve preguntando si SQL o NoSQL es mejor. Se resuelve identificando el modelo, las invariantes, las consultas, el volumen, la consistencia y la capacidad operativa que necesita una parte concreta del sistema.
Una base de datos es un conjunto de capacidades y compromisos, no una etiqueta.
Dos productos clasificados como documentales pueden ofrecer transacciones, índices, replicación y consistencia muy diferentes. Dos motores relacionales pueden comportarse distinto bajo particiones, failover o cargas distribuidas.
Por eso la decisión debe formularse así:
necesidad del dominio
+ patrón de acceso
+ garantía requerida
+ escala y distribución
+ capacidad operativa
→ tecnología y configuración adecuadasLa misma aplicación puede utilizar más de una tecnología, pero cada motor adicional debe resolver un problema importante. Polyglot persistence sin necesidad real multiplica migraciones, permisos, incidentes y conocimiento especializado.
Elegir almacenamiento por moda suele producir uno de estos resultados:
La tecnología correcta no elimina el modelado. Hace que las operaciones dominantes y las garantías importantes sean naturales y operables.
Identifica la unidad de consistencia. Si un pedido, sus líneas y su total deben cambiar de forma atómica, el almacenamiento debe permitir proteger esa invariante de manera razonable.
No diseñes únicamente para escrituras. Define consultas dominantes, filtros, orden, paginación, agregaciones y necesidad de joins o recorridos.
Saldo, reserva de stock y autorización suelen exigir garantías más fuertes que un feed, un contador o una vista analítica.
Considera tamaño total, crecimiento, tasa de escritura, picos, retención, regiones y tamaño de cada registro.
Pregúntate cómo se agregan campos, se migran relaciones, se ejecutan backfills y conviven versiones.
Backups, restore, upgrades, seguridad, observabilidad, costos y experiencia del equipo son parte de la decisión.
Una base relacional organiza datos en tablas conectadas mediante claves y restricciones.
Su fortaleza no es únicamente SQL. Es la combinación de:
CREATE TABLE orders (
id uuid PRIMARY KEY,
tenant_id uuid NOT NULL,
status text NOT NULL,
total numeric(14, 2) NOT NULL CHECK (total >= 0),
created_at timestamptz NOT NULL
);
CREATE TABLE order_items (
order_id uuid NOT NULL REFERENCES orders(id),
product_id uuid NOT NULL,
quantity integer NOT NULL CHECK (quantity > 0),
unit_price numeric(14, 2) NOT NULL CHECK (unit_price >= 0),
PRIMARY KEY (order_id, product_id)
);Aquí el motor protege parte de la integridad incluso si existe un error en la aplicación. La base no reemplaza reglas de dominio, pero funciona como última defensa.
Almacena objetos o documentos con estructura jerárquica.
Es útil cuando una unidad se lee y escribe junta y su forma puede variar de manera controlada.
{
"orderId": "o-10",
"tenantId": "t-1",
"status": "confirmed",
"items": [
{ "productId": "p-1", "quantity": 2, "unitPrice": 15000 }
],
"total": 30000
}Un documento puede crecer sin límite, concentrar conflictos y duplicar información. Si cada consulta necesita combinar colecciones, quizá el modelo no corresponde al patrón de acceso.
No asumas que documental significa sin transacciones. Revisa capacidades reales, alcance transaccional y costo. También verifica constraints disponibles; algunas invariantes quedarán en aplicación.
Ofrece acceso directo mediante una clave.
session:{token} → datos de sesión
rate-limit:{tenant}:{minute} → contadorEs excelente para sesiones, caché, locks cuidadosamente diseñados o estado efímero. No es una sustitución automática de una base transaccional.
Organiza grandes volúmenes distribuidos alrededor de claves de partición y patrones de acceso conocidos.
El modelado suele comenzar desde las consultas:
consulta requerida
→ partition key
→ clustering order
→ tabla denormalizada específicaModela nodos y relaciones como elementos de primera clase.
Es apropiado cuando el valor principal está en recorridos variables:
No es necesario usar una base de grafos para cualquier dato relacionado. Si las consultas son simples y estables, una relacional puede resolverlas con menor complejidad.
Un search engine optimiza texto, relevancia, filtros y agregaciones.
Catálogo es fuente de verdad
→ evento o CDC
→ índice de búsqueda
→ consultas de texto y filtrosEl índice suele ser derivado. Puede tener retraso, perder documentos temporalmente o requerir reconstrucción. No debería decidir precio, stock o autorización sin consultar una autoridad apropiada.
Está orientada a datos con timestamp, ingestión alta, retención y agregaciones por ventanas.
Es adecuada para métricas, telemetría y sensores. Puede comprimir, downsamplear y expirar datos de forma eficiente.
No reemplaza necesariamente una base operacional; las consultas y garantías son distintas.
SQL describe un lenguaje y una tradición relacional. NoSQL agrupa tecnologías muy diferentes. La comparación práctica debe hacerse por capacidad.
| Pregunta | Relacional | Documento | Clave–valor |
|---|---|---|---|
| Relaciones | Joins y constraints naturales | Embebido o referencias manuales | No es su fortaleza |
| Consultas | Flexibles | Buenas sobre forma prevista | Principalmente por clave |
| Unidad típica | Filas relacionadas | Documento o agregado | Valor individual |
| Integridad | Constraints maduros | Depende del motor y aplicación | Limitada al modelo de clave |
Esta tabla no sustituye revisar el producto concreto.
El almacenamiento debe favorecer las operaciones principales.
Consultas:
Posible arquitectura:
PostgreSQL
→ autoridad de producto, precio y relaciones
Search index
→ búsqueda de texto y filtros derivados
Redis
→ caché de respuestas públicas frecuentesNo es obligatorio usar tres motores. Se introducen solo cuando la carga y funcionalidad lo justifican.
Reduce duplicación y centraliza hechos.
Beneficios:
Costos:
Duplica datos para optimizar lectura o distribución.
Beneficios:
Costos:
La pregunta no es cuál es más profesional. Es dónde conviene pagar el costo: escritura y sincronización o lectura y combinación.
Antes de adoptar un motor, verifica:
El marketing de “strong consistency” puede aplicarse solo a ciertas operaciones o configuraciones.
Antes de distribuir, mide:
Sharding añade routing, rebalanceo, operaciones cruzadas, backups y fallos parciales. Debe responder a un límite medido.
Usar varias bases es razonable cuando las necesidades son realmente distintas.
Ejemplo DomiSys:
pedidos, pagos e inventario
→ PostgreSQL
sesiones y rate limiting
→ Redis
búsqueda avanzada de catálogo
→ índice derivado cuando sea necesario
métricas de plataforma
→ sistema de telemetría especializadoCada tecnología necesita:
Si el equipo no puede operar ese costo, la solución no es sostenible.
Necesita estados, líneas, totales, transacciones y consultas variables. Una relacional encaja naturalmente.
Necesita actualizaciones atómicas, constraints e historial. Relacional también es una opción fuerte.
Acceso por token, TTL y baja latencia. Una clave–valor puede aportar valor.
Si el catálogo crece y requiere relevancia, tolerancia a errores y filtros complejos, un índice derivado puede justificar su operación.
Al inicio pueden resolverse con consultas y réplicas. A gran escala, un warehouse evita cargar la base operacional.
Una base documental diseñada para lectura completa puede volverse incómoda si aparecen consultas cruzadas. Se puede añadir una proyección antes de migrar toda la autoridad.
Divide información con ciclos de vida distintos. No incrustes por conveniencia si el conjunto crece sin límite.
Una clave como fecha actual puede concentrar todas las escrituras. Revisa distribución y posibilidad de buckets.
La UI debe conocer la posibilidad de staleness y la operación necesita replay o reindexación.
Si Redis falla, define si se consulta origen, se degrada o se rechaza carga. No permitas que una caché secundaria destruya disponibilidad.
Ambas familias pueden escalar y fallar de formas diferentes. La afirmación ignora configuración, access patterns y costo de distribución.
La experiencia del equipo importa, pero debe compararse con el riesgo del dominio.
Produce scans, joins en aplicación o duplicación accidental. Parte de consultas e invariantes.
Cada motor parece ideal aisladamente, pero el sistema completo se vuelve imposible de operar.
Search y caché priorizan disponibilidad o consulta; pueden no ofrecer la integridad necesaria.
No elijas mediante un benchmark genérico. La carga debe representar tu sistema.
Revisa la decisión cuando:
Índices, transacciones y niveles de aislamiento profundiza en cómo una base relacional ejecuta consultas, protege invariantes y coordina operaciones concurrentes.