Las tres formas de almacenar datos
La mayoría de las bases de datos caen en tres familias. No necesitas memorizar productos: necesitas reconocer qué forma encaja con tu problema.
| Tipo | Ejemplos | Mejor para | Compensaciones |
|---|---|---|---|
| Relacional () | PostgreSQL, MySQL, SQLite | Datos estructurados con relaciones; cualquier cosa crítica en dinero o precisión | Debes diseñar un esquema de antemano; escalar escrituras muy grandes es más difícil |
| Documento / | MongoDB, Firestore, DynamoDB | Datos flexibles o anidados, iteración rápida, formas de registro variadas | Fácil de crear datos inconsistentes; las relaciones y los informes se vuelven torpes |
| Clave-valor | Redis, Memcached, Cloudflare KV | , sesiones, contadores, búsquedas rápidas por una clave conocida | Sin consultas por contenido; normalmente no es tu fuente de verdad |
Las tres formas almacenan datos de maneras genuinamente distintas. Imagínalas lado a lado:
RELATIONAL (SQL) DOCUMENT (NoSQL) KEY-VALUE
rows + columns self-contained blobs one key → one value
┌────┬───────┬──────┐ ┌──────────────────┐ ┌─────────┬─────────┐
│ id │ email │ name │ │ { │ │ key │ value │
├────┼───────┼──────┤ │ id, email, │ ├─────────┼─────────┤
│ 1 │ a@... │ Ana │ │ name, │ │ session │ "x9f2" │
│ 2 │ b@... │ Bob │ │ posts: [ ... ] │ │ count │ "42" │
└────┴───────┴──────┘ │ } │ └─────────┴─────────┘
tables reference └──────────────────┘ no querying inside —
each other everything nested look up by key only
Piensa en una relacional como un conjunto de hojas de cálculo que saben referenciarse entre sí. El lenguaje que usas para hablar con una de ellas es SQL (Structured Query Language, lenguaje de consulta estructurado). Una buena opción por defecto para el 90% de los proyectos: empieza con una base de datos relacional (Postgres). Es madura, predecible, impone estructura y maneja las relaciones que las aplicaciones reales inevitablemente desarrollan. Recurre a los almacenes de documentos cuando tus datos son genuinamente amorfos, y a los almacenes clave-valor como una capa de apoyo (caché), no como tu almacén principal.
La trampa que hay que evitar es elegir por intuición. "NoSQL (bases de datos que no usan tablas SQL: almacenan registros flexibles y de forma libre) escala mejor" es cierto solo para un conjunto reducido de problemas que la mayoría de las aplicaciones nunca enfrenta, e incluso entonces el precio es renunciar a las garantías de consistencia que hacen que los datos sean confiables. Elige la forma que encaje con tus datos, no la que suene más impresionante en un video de diseño de sistemas. Cuando tengas dudas, lo relacional es la apuesta segura: siempre puedes añadir una caché o un almacén de documentos después, pero deshacer un modelo de datos NoSQL enredado es doloroso.