Search for a command to run...
👋 Hey there! I'm Juanjo, a Backend Software Engineer with a focus on API development. My colleagues know me as someone committed to quality and attention to detail, my friends know me as a funny guy who knows good places to eat food. This blog tries to blend both sides of me.
No comments yet. Be the first to comment.
¿Por qué he leído este libro? Poco antes de terminar 2025, alcancé la cifra de 14 libros leídos, de los cuales 4 eran de desarrollo de software. Casi todos se centraban en arquitectura y diseño de alto nivel, así que buscaba algo más práctico a la ho...
Repaso de las propiedades ACID en bases de datos y qué sistemas las implementan hoy en día.
La técnica que utilizan Cassandra y DynamoDB para rebalancear datos en sistemas distribuidos
Este teorema dice que un sistema distribuido solo puedes garantizar simultáneamente dos de estas tres propiedades: Consistency (consistencia) Availability (disponibilidad) Partition tolerance (tolerancia a particiones) ¿Pero qué significan estas...
Hoy vamos a hablar de algo un poco más amplio: los motores de bases de datos. A grandes rasgos, los podemos dividir en dos grandes categorías: OLTP (procesamiento de transacciones online): los que están optimizados para procesar transacciones. OLAP...
Estaba leyendo Designing Data-Intensive Applications de Martin Kleppmann y me acordé de cuando, en mi última empresa, teníamos que elegir una base de datos. Básicamente era: "vale, a buscar en internet qué base de datos escoger".
Pero creo que, en ese momento, me faltaban nociones básicas. Especialmente sobre cómo en el mundo del desarrollo de software hemos llegado hasta los distintos modelos de base de datos que existen ahora. Entender el por qué surgieron SQL y NoSQL ayuda bastante a saber qué decisiones toman los programadores al elegir una base de datos para su sistema.
En este post voy a comparar brevemente bases de datos relacionales y basadas en documentos (aunque también mencionaré grafos).
Creo que todos conocemos el modelo relacional. Cuando sabes los requisitos del sistema, lo típico es empezar a normalizar los datos: es decir, organizar los datos en tablas, cada una con sus filas (registros) y columnas (atributos), y definir relaciones entre ellas usando primary keys y foreign keys.
Para interactuar con este tipo de base de datos se utiliza SQL (Structured Query Language), lo cual te permite hacer consultas declarativas como si trabajaras con conjuntos matemáticos.
El "rollo NoSQL" surgió por dos tendencias muy distintas:
Bases de datos basadas en documentos, donde los datos vienen enteros en un solo documento y las relaciones entre documentos son poco frecuentes.
Bases de datos de grafos, que van justo al otro extremo: intentan modelar casos donde todo puede estar relacionado con todo.
A día de hoy, los tres modelos (relacional, documentos y grafos) se usan bastante y cada uno tiene sentido en su propio dominio.
Una base de datos basada en documentos permite guardar estructuras anidadas dentro del mismo documento padre. Por ejemplo, imagina un documento User que incluye un campo Schools, con una lista de colegios a los que fue ese usuario. Ahí estaríamos modelando una relación 1 a N directamente dentro del mismo documento.
En una base de datos relacional, eso serían dos tablas (User y School) relacionadas con una foreign key.
Cuando tienes relaciones simples (1 a 1, o incluso algunas N a N), ambos modelos pueden funcionar. La diferencia empieza a notarse cuando necesitas hacer muchas joins o cuando los datos están muy conectados.
He de decir que, tras los años, las bases de datos SQL se intentan parecer más a las bases de datos basadas en documentos (permitiendo el uso de JSON en columnas, entre otros), y las bases de datos basadas en documentos se intentan parecer más a las SQL, así ambas consiguen mayor flexibilidad para sus casos de uso.
Aquí te dejo una mini tabla para que te hagas una idea rápida:
| Característica | Relacional | Documentos | Grafos |
| Flexibilidad del esquema | ❌ Baja | ✅ Alta | ✅ Alta |
| Relaciones complejas (N a N) | ✅ Natural con joins | ⚠️ Requiere lógica en la aplicación | ✅ Muy natural |
| Modelo cercano a tu caso de uso en app | ❌ Menos | ✅ Más cercano | ⚠️ Depende del uso |
| Escalabilidad horizontal | ⚠️ Más difícil | ✅ Más fácil | ⚠️ Complejo |
Flexibilidad no significa caos: aunque no tengas un esquema rígido, sigue siendo tu responsabilidad controlar qué estás metiendo en la base de datos. Se suele decir que en relacional se valida al escribir y en documentos al leer.
Evita documentos enormes: aunque puedes guardar estructuras complejas (JSON, BSON, XML...), eso no significa que debas abusar. Si solo necesitas una parte del documento, la base de datos probablemente cargue todo. Además, cuando actualizas un documento, muchas veces se reescribe entero. Por eso suele recomendarse mantener los documentos pequeños y bien pensados.
Para relaciones N a N, las bases de datos de documentos no son lo ideal. Puedes denormalizar, pero entonces mantener la consistencia se vuelve más complicado. Y si usas código en la aplicación para simular joins, el rendimiento baja y la complejidad del código sube.
¿Tu modelo tiene datos muy conectados? → Relacional o grafos.
¿Necesitas flexibilidad, escalabilidad y acceso rápido a una estructura de datos entera y concreta para tu caso de uso? → Modelo basado en documentos.
¿Tienes muchas relaciones complejas N a N? → El modelo en documentos se te va a quedar corto.
Y como resumen simple:
👉 Para datos muy interconectados, el modelo en documento es 💩, el relacional es aceptable, y los grafos son lo más natural.