SQL vs NoSQL — ¿cómo decides realmente para un servicio nuevo?
Olvida los eslóganes de marketing — la decisión real depende de la forma de tus datos, tus requisitos de consistencia y tus patrones de consulta, no de cuál base de datos suena "más moderna".
APRENDE HACIENDOPon a prueba tu intuición3 pasos
SQL vs NoSQL — ¿cómo decides realmente para un servicio nuevo?
Usa los ejemplos y la explicación de la lección para comprobar tu idea.
Reflexión personal. No se envía a ningún servicio de IA.#Por qué "depende" no es una respuesta suficiente
Todo candidato backend ha escuchado esta pregunta, y la mayoría responde con el mismo guion gastado: "SQL es para datos estructurados, NoSQL para datos no estructurados." Esa frase no resiste ninguna repregunta — hay muchísimos esquemas relacionales que guardan columnas JSON semiestructuradas, y muchas bases de datos de documentos que en la práctica imponen una forma bastante rígida a nivel de aplicación. Una respuesta senior tiene que hablar de patrones de acceso, garantías de consistencia y forma operativa, no de vocabulario sacado de una presentación de marketing.
La pregunta real nunca es "¿cuál base de datos es mejor?" sino "¿cuál base de datos encaja con el problema que realmente tengo?" Eso implica entender para qué está optimizada cada familia, y pasar tus requisitos concretos por un marco de decisión corto en lugar de guiarte por intuición.
#Para qué está optimizada realmente cada familia
Una base de datos relacional (Postgres, MySQL, SQL Server) se construye alrededor de un esquema fijo, tipado fuerte, restricciones declarativas y joins entre tablas resueltos por un planificador de consultas. Su superpoder es garantizar invariantes entre muchas entidades a la vez — claves foráneas, restricciones de unicidad, transacciones multi-fila — sin dejar de permitirte hacer preguntas ad hoc sobre los datos con SQL.
NoSQL no es una sola cosa; son cuatro familias distintas que resuelven problemas distintos:
- Bases de documentos (MongoDB, DynamoDB en algunos modos) — guardan documentos semiestructurados, a menudo anidados, identificados por ID. Ideales cuando cada entidad es naturalmente autocontenida y se lee/escribe como un todo.
- Bases clave-valor (Redis, DynamoDB) — throughput extremo para operaciones simples de get/put por clave. Sin lenguaje de consultas, sin joins, solo búsquedas.
- Bases de columnas anchas (Cassandra, HBase) — pensadas para un volumen de escritura masivo y escalado horizontal, a costa de flexibilidad en las consultas (diseñas las tablas alrededor de tus patrones de acceso, no al revés).
- Bases de grafos (Neo4j) — optimizadas para recorrer relaciones muchos niveles de profundidad, algo que con joins en SQL se vuelve costoso rápidamente.
#Un marco de decisión que sí puedes usar en una entrevista
- ¿Cómo es la forma de los datos y cómo cambia? Una forma relacional fija con muchas consultas cruzadas entre entidades (pedidos que pertenecen a clientes que tienen direcciones) apunta a SQL. Documentos cuya forma varía por registro y que se leen/escriben completos (un perfil de usuario, una entrada de catálogo) apuntan a una base de documentos.
- ¿Cuál es el requisito de consistencia? Si necesitas transacciones multi-fila y multi-tabla con corrección estricta (movimiento de dinero, decrementos de inventario, cualquier caso donde "leer tu propia escritura" y la atomicidad entre filas importen), inclínate por relacional/ACID. Si la consistencia eventual es aceptable (un contador de "me gusta", un feed de actividad), una base NoSQL te da disponibilidad y escalado horizontal a cambio.
- ¿Cuál es el patrón de consulta? Reportes ad hoc, joins entre entidades que no anticipaste en el diseño → SQL. Un número pequeño de patrones de acceso conocidos a escala muy grande (traer usuario por ID, traer mensajes por ID de conversación) → clave-valor o columnas anchas, diseñadas exactamente para esos patrones.
- ¿Cuál es la escala y forma de crecimiento? Muchas bases NoSQL están construidas para particionarse horizontalmente desde el diseño. Las bases relacionales tradicionalmente escalan verticalmente o necesitan una estrategia explícita de sharding/réplicas de lectura — aunque esta línea se ha difuminado bastante con los motores SQL distribuidos que dan escala horizontal sin renunciar a SQL ni a las transacciones.
- ¿Qué es lo que tu equipo ya opera bien? La madurez operativa es un costo real. Un equipo que lleva cinco años corriendo Postgres en producción va a entregar una migración a NoSQL más lenta y con más errores que quedarse en relacional, aunque NoSQL sea en teoría un mejor encaje.
#El teorema CAP, brevemente, porque va a salir
El teorema CAP dice que ante una partición de red, un sistema distribuido debe elegir entre consistencia y disponibilidad — no puede tener ambas. La mayoría de las bases NoSQL son explícitas sobre en qué lado de esa línea se ubican (Cassandra por defecto es AP, MongoDB por defecto es más bien CP con consistencia ajustable), mientras que una base relacional de un solo nodo esquiva la pregunta porque no hay partición de la que preocuparse hasta que la distribuyes. Esta es una repregunta habitual, así que sepas de qué lado cae la base que elegiste y por qué eso importa para tu caso de uso.
#Tabla comparativa
| Dimensión | Relacional (SQL) | Documentos | Clave-Valor | Columnas anchas | Grafos |
|---|---|---|---|---|---|
| Esquema | Fijo, forzado | Flexible, por documento | Ninguno | Familias de columnas, flexible | Flexible (nodos/aristas) |
| Transacciones | Fuertes, multi-fila/tabla | Usualmente de un solo documento | Una sola clave | Limitadas | Varía |
| Flexibilidad de consulta | Alta (joins, SQL ad hoc) | Media (consulta por campo) | Baja (get/put por clave) | Baja (consulta por clave de partición) | Alta para relaciones |
| Escalado horizontal | Más difícil, mejorando | Nativo en la mayoría | Nativo | Nativo, es el punto central | Más difícil |
| Ideal para | Sistemas transaccionales, reportes | Catálogos, perfiles, CMS | Caché, sesiones | Series de tiempo, volumen de escritura enorme | Grafos sociales, recomendaciones, detección de fraude |
La mayoría de los sistemas reales terminan siendo poliglotas de todas formas: Postgres para el núcleo transaccional, Redis para caché y estado de sesión, Elasticsearch para búsqueda de texto completo, y tal vez Kafka o una base de columnas anchas para ingesta de eventos de alto volumen. La respuesta de entrevista no es "elijo una para siempre" — es demostrar que puedes razonar sobre qué motor de almacenamiento encaja con qué parte del problema.
#Ponte a prueba
🧠 Check your understanding
0/3 · 0/3 answered1. Un equipo necesita guardar datos de sesión de usuario con un throughput de lectura/escritura extremadamente alto, sin necesidad de joins, y la consistencia eventual es aceptable. ¿Qué tipo de almacenamiento encaja mejor?
2. Según el teorema CAP, ¿entre qué debe elegir una base de datos distribuida durante una partición de red?
3. ¿Por qué 'NoSQL significa sin esquema' es una respuesta engañosa en una entrevista?