La comparación «relacional vs NoSQL» está mal planteada, porque «NoSQL» agrupa cuatro modelos distintos: de documentos, de clave y valor, de columnas anchas y de grafos. Lo que de verdad los separa de una base relacional no es el lenguaje sino las garantías: las relacionales priorizan ACID —que el dato sea correcto cuando el motor confirma— y las distribuidas suelen priorizar BASE —que el sistema responda siempre, aceptando consistencia eventual—. La pregunta que resuelve la elección es una: ¿tu problema tolera leer un dato desactualizado? Si no, la respuesta es relacional.
Ver índice de contenidos
Por qué la pregunta está mal planteada
«¿Uso SQL o NoSQL?» es la pregunta que se hace todo el mundo, y tiene dos problemas de fondo.
El primero es que compara un lenguaje con una categoría. SQL es el lenguaje de consulta de las bases relacionales; «NoSQL» es una etiqueta que se le puso a todo lo demás. Es como preguntar «¿castellano o Europa?».
El segundo, y el más importante en la práctica: «NoSQL» no es un modelo, son cuatro, y son tan distintos entre sí como cualquiera de ellos lo es del relacional. Una base de clave y valor y una de grafos no tienen casi nada en común más que no ser relacionales.
Hoy suele leerse «NoSQL» como not only SQL —no solo SQL— en lugar de no SQL, porque varios de estos motores terminaron incorporando lenguajes de consulta bastante parecidos a SQL. El cambio de lectura reconoce lo que la etiqueta original hacía mal: definirse por lo que no es.
La pregunta útil, entonces, es: ¿cuál de los cinco modelos encaja con mi problema? Y para eso hay que conocerlos.
Los cinco modelos
Dos de ellos merecen una nota extra, porque son los que más se malinterpretan.
De documentos. Es el que más se compara con el relacional, y por eso conviene el vocabulario preciso. La documentación de MongoDB lo describe así: «MongoDB guarda los registros de datos como documentos en colecciones. Una base de datos contiene una o más colecciones». La equivalencia mental es que una colección se parece a una tabla y un documento a una fila, con la diferencia clave de que cada documento puede tener campos distintos.
De clave y valor. Es el modelo más simple y el más rápido: guardás un valor y lo recuperás por su clave, y el motor no sabe ni le importa qué hay adentro. Esa simplicidad es su virtud y su límite: no se puede consultar por contenido. Si necesitás «todos los usuarios de Córdoba», este modelo no sirve, porque solo sabe buscar por clave.
ACID y BASE: el eje real
Acá está la diferencia que importa, y no tiene nada que ver con tablas ni con documentos: tiene que ver con qué te garantiza el motor.
ACID
Es el conjunto de garantías del mundo relacional clásico: atomicidad (una operación se completa entera o no se completa), consistencia (la base pasa de un estado válido a otro válido), aislamiento (las transacciones concurrentes no se ven entre sí a medias) y durabilidad (lo confirmado sobrevive a una caída).
La documentación de PostgreSQL explica la atomicidad con una claridad difícil de mejorar: una transacción «agrupa varios pasos en una única operación de todo o nada», y «si ocurre alguna falla que impide completarla, entonces ninguno de los pasos afecta a la base de datos».
BASE
Es el conjunto de prioridades habitual en sistemas distribuidos: disponibilidad básica, estado blando y consistencia eventual. El sistema responde siempre, y los distintos nodos terminan coincidiendo «al rato».
Eso no es un defecto: es una elección deliberada. Cuando los datos están repartidos en cien servidores, esperar a que los cien confirmen antes de responder haría el sistema lento y frágil. Aceptar que la coincidencia llegue con retraso es lo que permite que responda rápido y siga funcionando si un nodo se cae.
¿Tu problema tolera leer un dato desactualizado? Si en la cuenta de alguien puede figurar un saldo viejo, o el stock puede mostrar una unidad que ya se vendió, o una historia clínica puede no tener la última anotación, entonces la conversación termina ahí: necesitás garantías fuertes, y eso es una base relacional. Si estás mostrando la cantidad de «me gusta» de una publicación y durante dos segundos dice 41 en lugar de 42, no le importa a nadie.
Escalar: vertical y horizontal
El argumento más repetido a favor de las bases no relacionales es que «escalan mejor». Es parcialmente cierto y conviene precisarlo, porque hay dos formas de escalar.
| Forma | En qué consiste | Su límite |
|---|---|---|
| Vertical | Un servidor más grande: más memoria, más procesadores, discos más rápidos | Existe un servidor máximo, y el precio crece más rápido que la capacidad |
| Horizontal | Más servidores repartiendo los datos entre ellos | Coordinar muchos nodos es difícil, y ahí es donde se pierden garantías |
Los motores no relacionales suelen estar diseñados desde el principio para el escalado horizontal, y eso los hace genuinamente más simples de repartir. Los relacionales pueden hacerlo también, pero con más trabajo, porque mantener garantías ACID entre nodos es costoso: eso no es una limitación accidental, es el precio de la garantía.
Dicho eso, hay dos matices que rara vez se mencionan. El primero es que un servidor relacional bien configurado aguanta muchísimo más de lo que se supone, y la abrumadora mayoría de los proyectos nunca llega a ese límite. El segundo es que la facilidad para escalar horizontalmente se paga renunciando a garantías que después hay que reimplementar en la aplicación, y hacerlo bien es más difícil que administrar una base relacional.
El costo del esquema flexible
La otra ventaja que se nombra siempre es el «esquema flexible»: no hace falta declarar la estructura antes de guardar. Es real, y es especialmente útil cuando la forma del dato varía entre registros o cambia seguido.
Pero la frase que conviene tener presente es esta: el esquema no desaparece, cambia de lugar. Sigue existiendo, solo que ahora vive en tu código en lugar de en la base, y quien tiene que hacerlo cumplir sos vos.
| Quién garantiza… | Relacional | Esquema flexible |
|---|---|---|
| Que el campo exista | El motor (NOT NULL) | Tu código, en cada lugar que escriba |
| Que el tipo sea correcto | El motor (tipo de columna) | Tu código |
| Que el vínculo apunte a algo real | El motor (clave foránea) | Tu código |
| Que el nombre del campo sea el mismo | El motor (la columna es una) | Nadie, salvo disciplina del equipo |
Esa última fila es la que genera más problemas a mediano plazo. Si tres partes distintas del código escriben en la misma colección, nada impide que una use correo, otra email y otra mail. En una tabla, eso es imposible por construcción.
La conclusión honesta: el esquema flexible es una ventaja cuando la variabilidad es parte del problema, y una fuente de deuda cuando se elige simplemente para no tener que pensar la estructura al principio.
Cómo elegir en la práctica
Cuatro preguntas en orden. La primera que dé una respuesta clara, decide.
- ¿Puede haber datos desactualizados o inconsistentes por un momento?Si la respuesta es no —dinero, stock, salud, identidad— elegí relacional y no sigas leyendo. Ninguna otra ventaja compensa.
- ¿Las relaciones entre los datos son el centro del problema?Si lo que consultás son caminos y conexiones —«amigos de amigos», «quién está vinculado con quién»— una base de grafos hace en una consulta lo que en SQL requiere varios niveles de unión.
- ¿Solo necesitás recuperar por una clave, muy rápido y sin consultar contenido?Caché, sesiones, contadores, límites de peticiones. Ahí una base de clave y valor es la herramienta correcta, y normalmente además de la principal, no en su lugar.
- ¿La forma del dato varía mucho entre registros y no hay relaciones fuertes?Catálogos con atributos muy distintos por categoría, registros de eventos, contenido heterogéneo. Ahí una base de documentos encaja bien.
Si ninguna de las cuatro te dio una respuesta clara, la respuesta es relacional. No por conservadurismo, sino porque es el modelo que menos supuestos te impone y el que tiene el ecosistema más grande, la mayor cantidad de material y el vocabulario más transferible entre trabajos.
Usar las dos a la vez
La pregunta «¿cuál elijo?» supone que hay que elegir una sola, y en la práctica muchos sistemas usan varias. Eso se llama persistencia poliglota, y bien hecho es una arquitectura sensata.
El patrón más común: una base relacional como fuente de verdad para los datos que importan —usuarios, pedidos, pagos— y una base de clave y valor al costado para las sesiones, la caché y los contadores. Cada motor haciendo lo que hace bien.
Una sola fuente de verdad por dato. El mismo dato puede estar copiado en varios motores, pero uno solo tiene la autoridad y los demás son copias derivadas que se pueden reconstruir. Lo que sale mal es tener el mismo dato en dos motores sin decidir cuál manda: tarde o temprano se contradicen, y no hay forma de saber cuál está bien.
Y una advertencia de costo que no aparece en los diagramas: cada motor extra suma trabajo de administración, respaldos, permisos, actualizaciones y personas que sepan operarlo. Sumar un motor porque encaja mejor con un caso es razonable; sumarlo por curiosidad es deuda.
Cuatro mitos que conviene desarmar
- «Las no relacionales no tienen transacciones.» Ya no es cierto en general: varios motores de documentos incorporaron transacciones sobre múltiples documentos. Lo que sigue siendo cierto es que su alcance y su costo varían, y conviene leer la documentación del motor concreto en lugar de suponer.
- «Las relacionales no escalan.» Escalan bastante más de lo que se cree, y la mayoría de los proyectos nunca llega al límite de un servidor bien configurado. El problema de rendimiento típico no es el motor: son consultas sin índice y un diseño que repite datos.
- «NoSQL es más moderno.» La antigüedad de un modelo no dice nada sobre su adecuación. El modelo relacional se formuló en 1970 y sigue siendo dominante porque resuelve bien el problema más común. El sistema de archivos también es viejo y nadie propone reemplazarlo por moda.
- «Sin esquema se desarrolla más rápido.» Al principio sí. A los seis meses, cuando hay que averiguar qué campos existen de verdad en una colección con un millón de documentos escritos por tres versiones distintas del código, la cuenta cambia.
Errores frecuentes al elegir
- Elegir por la popularidad del motor. Que algo aparezca mucho en artículos no dice nada sobre si encaja con tu problema.
- Elegir pensando en una escala que no tenés. Diseñar para millones de usuarios cuando tenés cien agrega complejidad hoy por un beneficio hipotético.
- Usar una base de documentos para datos muy relacionados. Termina reimplementando uniones en el código de la aplicación, más lento y con más errores.
- Usar clave y valor como base principal. No se puede consultar por contenido: el día que necesites «todos los de tal ciudad», no hay forma.
- Renunciar a ACID sin saberlo. Es la más costosa: se descubre cuando aparece un saldo que no cierra y nadie puede explicar por qué.
- Sumar motores sin sumar capacidad de operarlos. Cada uno trae respaldos, permisos, actualizaciones y su propia forma de fallar.
- Creer que sin esquema no hay que diseñar. El diseño sigue siendo necesario; lo único que cambia es quién lo hace cumplir.
Preguntas frecuentes
¿Qué significa NoSQL exactamente?
Es un nombre poco afortunado que agrupa a todo lo que no es relacional, y esconde que no se trata de un modelo sino de cuatro modelos bastante distintos entre sí: de documentos, de clave y valor, de columnas anchas y de grafos. Hoy suele leerse como «not only SQL» en lugar de «no SQL», porque varios de estos motores incorporaron lenguajes de consulta parecidos. La consecuencia práctica es que la pregunta «¿uso SQL o NoSQL?» está mal planteada: hay que preguntar cuál de los cinco modelos encaja con el problema.
¿Cuál es la diferencia entre ACID y BASE?
Son dos conjuntos de garantías con prioridades opuestas. ACID —atomicidad, consistencia, aislamiento y durabilidad— prioriza que el dato sea correcto: cuando el motor confirma una operación, está guardada y la base quedó en un estado válido. BASE prioriza que el sistema responda siempre, aceptando que los distintos nodos coincidan «al rato», lo que se llama consistencia eventual. El costo de ACID es que coordinar muchos nodos es caro; el costo de BASE es que una lectura puede devolver un dato desactualizado.
¿Es cierto que NoSQL escala mejor?
Es cierto para escalado horizontal, y con un matiz importante. Los motores no relacionales suelen estar diseñados desde el principio para repartir los datos entre muchos servidores, y eso los hace más simples de escalar así. Pero el matiz es doble: primero, los motores relacionales modernos también escalan mucho más de lo que suele creerse, y muy pocos proyectos llegan al límite de un servidor bien configurado; segundo, la facilidad para escalar se paga renunciando a garantías que después hay que reimplementar en la aplicación, y hacerlo bien es más difícil que administrar una base relacional.
¿Puedo usar las dos en el mismo proyecto?
Sí, y es una arquitectura habitual y sensata: se llama persistencia poliglota. El patrón más común es una base relacional como fuente de verdad para los datos que importan, más una base de clave y valor como caché o para las sesiones. Lo importante es que cada motor tenga un rol claro y una sola fuente de verdad por dato. Lo que sale mal es tener el mismo dato en dos motores sin decidir cuál manda, porque tarde o temprano se contradicen y no hay forma de saber cuál está bien.
¿Los motores no relacionales no tienen esquema?
Tienen esquema, pero no lo hace cumplir el motor: lo hace cumplir tu código. Eso es lo que se llama «esquema flexible», y es una ventaja real cuando la forma del dato varía entre registros o cambia seguido. Pero conviene entender el intercambio: la estructura sigue existiendo, solo que ahora la responsabilidad de que sea coherente pasa de la base a la aplicación. Si tres partes distintas del código escriben en la misma colección, nada impide que cada una use nombres de campo distintos.
¿Con qué debería empezar si estoy aprendiendo?
Con una relacional, por tres razones concretas. La primera es que cubre la enorme mayoría de los casos reales. La segunda es que SQL es la habilidad más transferible del rubro: sirve en cualquier motor relacional y en muchas herramientas de análisis. Y la tercera, la más importante, es que el modelo relacional te obliga a pensar la estructura de los datos, y ese razonamiento después se aplica a cualquier otro modelo. Al revés no funciona igual: empezar por un modelo sin restricciones enseña menos sobre cómo se organizan los datos.
Fuentes
Documentación oficial consultada para esta guía. Fecha de consulta: 27 de julio de 2026.
- MongoDB. Databases and Collections. Vocabulario del modelo de documentos: documentos, colecciones y su relación con la base de datos.
- PostgreSQL. Transactions. Definición de transacción como operación de todo o nada, base de las garantías ACID.
- PostgreSQL. Concepts. El modelo relacional y la mención de otras formas de organizar bases de datos.
- Redis. Data types. Estructuras disponibles en un motor de clave y valor.
- Underc0de, foro. Sección Base de Datos. Material de la comunidad sobre motores y modelado.