SQL (relacional) vs NoSQL
La decisión que más se toma por moda y menos por análisis. La respuesta aburrida —y correcta en la mayoría de proyectos— es que una base de datos relacional te va a ir bien.
Datos en tablas con esquema fijo y relaciones
Datos en documentos, claves o grafos, sin esquema rígido
Una base relacional impone un esquema y garantiza que los datos son coherentes: si una transacción falla, no queda nada a medias. NoSQL relaja esas garantías a cambio de flexibilidad de forma y facilidad para repartir la carga entre muchas máquinas. La pregunta no es cuál es mejor, es si tu problema justifica renunciar a las garantías.
| Dimensión | SQL (relacional) | NoSQL |
|---|---|---|
| Esquema | Fijo y validado | Flexible, definido por la aplicación |
| Consistencia | Transacciones ACID | Habitualmente eventual |
| Consultas complejas | Su punto fuerte: joins y agregaciones | Limitadas o hay que duplicar datos |
| Escalado | Vertical, y horizontal con esfuerzo | Horizontal por diseño |
| Cambios de estructura | Migraciones explícitas | Inmediatos, pero la deuda se acumula |
| Madurez del ecosistema | Décadas de herramientas | Muy variable según el motor |
Por defecto, y sobre todo cuando los datos tienen relaciones entre sí, cuando hace falta consistencia —cualquier cosa que toque dinero, stock o facturación— o cuando vas a hacer consultas que no tienes previstas todavía.
Cuando la forma del dato es genuinamente irregular, cuando el volumen exige repartir entre muchas máquinas desde el principio, o para casos concretos: caché, series temporales, búsqueda, grafos.
Elegir NoSQL por el escalado que no vas a necesitar. Una base relacional en una máquina razonable aguanta muchísimo más de lo que casi cualquier proyecto llega a exigirle, y renunciar a las transacciones para prepararse a un volumen hipotético cuesta caro cuando aparece el primer descuadre de stock que nadie sabe explicar.