Bases de datos para empezar: SQL vs NoSQL sin dogma
Arnold Wender · · 11 min de lectura
Ver todo: Programación“¿Qué base de datos debería aprender?”
Es la segunda pregunta más repetida en canales de Discord de backend, justo después de “¿qué lenguaje aprendo primero?”. Y la respuesta que se repite —“usa MongoDB, es más flexible”— es igual de inútil que recomendar Python sin preguntar para qué. Porque la elección entre SQL y NoSQL no depende de cuál es mejor en abstracto. Depende de qué estás construyendo y qué garantías necesita tu sistema.
Esta guía te da el criterio real para elegir, sin marketing de bases de datos y sin religión tecnológica.
Lo que importa antes de elegir
- Los datos relacionales necesitan SQL — si tienes entidades que se relacionan entre sí (usuarios → pedidos → productos), un motor relacional es la elección natural
- NoSQL no es “SQL sin esquema” — es un conjunto de modelos distintos (documentos, clave-valor, grafos, columnas) con trade-offs propios
- PostgreSQL 17/18 hace la mayor parte del trabajo — incluyendo casos que antes requerían NoSQL (JSON nativo, búsqueda vectorial)
- MongoDB y Redis no compiten entre sí — resuelven problemas completamente distintos dentro del ecosistema NoSQL
- La arquitectura poliglota es estándar en sistemas medianos y grandes: SQL para transacciones + Redis para caché + búsqueda con otra herramienta
- Empieza con PostgreSQL si no sabes por dónde — aprenderás fundamentos que aplican en cualquier otro motor
Si quieres ver el resto del ecosistema para backend y herramientas de desarrollo, visita Programación en Geekshop.
La distinción que nadie explica bien
SQL y NoSQL no son dos lados de una competencia. Son dos categorías distintas con filosofías distintas sobre cómo almacenar y consultar datos.
SQL (Structured Query Language) es el lenguaje estándar para bases de datos relacionales. Los motores que lo implementan —PostgreSQL, MySQL, SQLite, SQL Server— almacenan datos en tablas con filas y columnas, definen relaciones entre tablas mediante claves foráneas, y garantizan consistencia transaccional mediante las propiedades ACID (Atomicidad, Consistencia, Aislamiento, Durabilidad).
NoSQL es un paraguas que cubre varios modelos distintos:
- Documentos: MongoDB, CouchDB — datos en JSON/BSON
- Clave-valor: Redis, DynamoDB — lookup ultrarrápido por clave
- Columnar: Cassandra, ClickHouse — optimizado para analítica a escala
- Grafos: Neo4j — relaciones complejas entre nodos
Lo primero que tienes que entender: cuando alguien dice “usa NoSQL”, es como decir “usa herramientas de taller” sin especificar si necesitas un martillo o una sierra. El modelo importa.
EL MODELO RELACIONAL
SQL: cuando tus datos tienen estructura clara y relaciones
Las bases de datos relacionales llevan décadas siendo el estándar por una razón: modelan bien la realidad de la mayoría de aplicaciones de negocio.
Un sistema de e-commerce tiene usuarios. Los usuarios tienen pedidos. Los pedidos tienen líneas de producto. Los productos pertenecen a categorías. Todas esas relaciones —expresadas en tablas con claves foráneas— son exactamente para lo que SQL fue diseñado. Y cuando necesitas una consulta como “dame todos los pedidos de usuarios de Guadalajara del último mes agrupados por categoría de producto”, SQL te lo resuelve en una sola consulta con JOINs.
PostgreSQL, actualmente en versión 17 (con 18 ya disponible), es el motor open source más completo del mercado en 2026. Soporta JSON nativo con índices, búsqueda de texto completo, búsqueda vectorial (con pgvector), particionamiento de tablas y extensiones para prácticamente cualquier caso de uso. Es el punto de entrada recomendado si vas a aprender SQL desde cero.
El modelo de documentos y cuándo tiene sentido
BASES DE DATOS DE DOCUMENTOS
MongoDB: flexibilidad de esquema con trade-offs reales
MongoDB 8.0 (versión de parche actual: 8.0.17) almacena datos como documentos BSON —básicamente JSON enriquecido— en colecciones. La ventaja principal no es que “sea más fácil”: es que permite esquemas flexibles, donde documentos en la misma colección pueden tener estructuras distintas.
Eso es genuinamente útil cuando:
- Estás construyendo un catálogo de productos con atributos variables (un laptop tiene RAM y núcleos; una camiseta tiene talla y color; un libro tiene ISBN y número de páginas — difícil modelar con una tabla uniforme)
- Tienes datos jerárquicos densos que rara vez consultas de forma relacional (configuraciones de usuario, metadatos de eventos, logs estructurados)
- Tu esquema cambia frecuentemente durante el desarrollo temprano y no quieres gestionar migraciones de tabla
El trade-off real de MongoDB es consistencia. Por defecto, no tienes transacciones ACID multi-documento de forma gratuita. Las transacciones multi-documento existen desde MongoDB 4.x, pero añaden overhead. Si tu aplicación necesita “debitar una cuenta y acreditar otra en la misma operación atómica”, PostgreSQL sigue siendo la respuesta correcta.
Tabla comparativa: los cinco motores que más vas a ver
| Motor | Modelo | Versión actual | Mejor para | Curva inicial |
|---|---|---|---|---|
| PostgreSQL | Relacional | 17.x / 18.x | Aplicaciones de negocio, datos relacionales, transacciones | Media |
| MySQL | Relacional | 8.4 LTS / 9.6 Innovation | Web apps, WordPress/LAMP, legado | Baja |
| SQLite | Relacional embebido | 3.x | Apps móviles, prototipos, archivos locales | Muy baja |
| MongoDB | Documentos | 8.0.17 | Catálogos, CMS, esquemas flexibles | Media |
| Redis | Clave-valor en memoria | 8.8.0 | Caché, sesiones, colas, tiempo real | Baja |
Nota sobre MySQL: Oracle mantiene dos tracks desde MySQL 9: la rama LTS (8.4, soporte a largo plazo) y la rama Innovation (9.x, con nuevas features como el tipo VECTOR). Para proyectos nuevos, PostgreSQL tiene mejor soporte de extensiones y estándares SQL; MySQL sigue siendo dominante en stacks heredados y hosting compartido.
Redis no es una base de datos principal (y eso está bien)
Redis 8.8.0 merece una mención especial porque aparece en prácticamente todos los stacks de producción modernos, pero muchos principiantes lo malentienden.
Redis es un almacén de datos en memoria. Es ultrarrápido (latencia de microsegundos) porque todo vive en RAM. Eso lo hace ideal para:
- Caché de consultas costosas — almacena el resultado de una consulta PostgreSQL pesada y sírvelo en microsegundos la próxima vez
- Sesiones de usuario — guardar tokens de autenticación temporales
- Colas de trabajo — pub/sub, listas de tareas pendientes (con Redis Streams o módulos como BullMQ)
- Rate limiting — contar peticiones por usuario en ventanas de tiempo
Lo que Redis no es: tu base de datos principal de negocio. Los datos en Redis son efímeros por diseño (aunque puede persistirse a disco). Piénsalo como una capa de aceleración encima de tu base de datos principal, no como su reemplazo.
A partir de Redis 8.0 (lanzado en 2025), Redis cambió a un modelo de triple licencia: RSALv2, SSPLv1 o AGPLv3. Si esto afecta tu proyecto depende de tu caso de uso; para uso interno en aplicaciones propias, generalmente no hay problema.
La arquitectura poliglota no es complejidad gratuita — es usar cada herramienta para lo que fue diseñada: PostgreSQL para transacciones, Redis para velocidad, y la combinación correcta según el problema.
ACID vs BASE: el trade-off real que nadie te explica
Detrás del debate SQL vs NoSQL hay un trade-off de consistencia que vale la pena entender antes de elegir.
Los motores relacionales garantizan propiedades ACID:
- Atomicidad — una transacción se completa entera o no se ejecuta
- Consistencia — los datos siempre pasan de un estado válido a otro
- Aislamiento — transacciones concurrentes no se interfieren entre sí
- Durabilidad — una vez confirmada, la transacción persiste aunque el sistema falle
Muchos sistemas NoSQL (especialmente los distribuidos) sacrifican consistencia a cambio de disponibilidad y tolerancia a particiones. Esta clase de sistemas sigue el modelo BASE:
- Basically Available — siempre responden, aunque sea con datos potencialmente desactualizados
- Soft state — el estado puede cambiar incluso sin input del usuario
- Eventually consistent — eventualmente, los datos convergen a un estado consistente
Para la mayoría de aplicaciones que construirás al inicio —backends de apps, APIs REST, sistemas de gestión— quieres ACID. Las garantías BASE son relevantes en sistemas distribuidos a escala de millones de usuarios, donde el costo de sincronización perfecta es inaceptable. No sobre-ingenierices para ese problema si todavía no lo tienes.
Cómo empezar: un camino práctico
RUTA DE APRENDIZAJE
PostgreSQL primero, después el resto
Si eres principiante en bases de datos, este es el camino que tiene más sentido:
Fase 1 — SQL fundamental con PostgreSQL. Instala PostgreSQL localmente (o usa Neon para tener una instancia gratuita en la nube sin setup). Aprende SELECT, INSERT, UPDATE, DELETE. Luego JOINs: INNER JOIN, LEFT JOIN. Después GROUP BY, HAVING, subqueries. Cuando entiendas cómo funcionan las relaciones y los índices, tendrás fundamentos que aplican en cualquier motor relacional.
Fase 2 — Modelado de datos. Aprende a diseñar un esquema correcto. Normalización (1NF, 2NF, 3NF) no es teoría académica inútil — es la diferencia entre una base de datos que escala y una que se vuelve un desastre de duplicación. Practica diseñando esquemas para sistemas reales: e-commerce, blog, sistema de reservas.
Fase 3 — Explora MongoDB en un proyecto real. No aprendas MongoDB en abstracto. Toma un proyecto con requisitos que encajen: un catálogo de productos con atributos variables, un CMS de contenido, una aplicación de logs. Instala MongoDB localmente o usa MongoDB Atlas en su tier gratuito.
Fase 4 — Añade Redis a tu stack. Cuando tengas una aplicación corriendo con PostgreSQL, añade Redis para cachear las consultas más lentas. Eso te enseña la arquitectura poliglota en la práctica, no en teoría.
Errores comunes al aprender bases de datos
El contexto de 2026: PostgreSQL avanza más rápido que nunca
Una nota importante sobre el estado actual del ecosistema: la brecha entre lo que puede hacer PostgreSQL y lo que “requiere” NoSQL se ha reducido significativamente en los últimos años.
PostgreSQL 17/18 soporta:
- JSON/JSONB nativo con índices GIN — puedes almacenar documentos flexibles en PostgreSQL sin necesidad de MongoDB
pgvector— búsqueda vectorial para aplicaciones de IA/ML directamente en SQL- Particionamiento de tablas — para escalar tablas de cientos de millones de filas
- Logical replication — para arquitecturas distribuidas
Esto no significa que MongoDB o Redis son obsoletos. Significa que si tu único argumento para usar MongoDB era “flexibilidad de esquema”, ahora tienes esa opción también en PostgreSQL con JSONB. El caso de MongoDB se fortalece en cargas de trabajo puramente orientadas a documentos y en escalado horizontal nativo. El caso de Redis es tan claro como siempre.
La decisión ya no es “SQL vs NoSQL” como framework filosófico. Es “¿qué modelo de datos encaja mejor con este problema específico?”
Links para profundizar
Esta guía cubre los fundamentos. Para el contexto de herramientas y flujo de trabajo práctico de un desarrollador backend, lee Las herramientas que de verdad usan los desarrolladores. Y si estás eligiendo en qué lenguaje programarás el backend que se conecta a estas bases de datos, empieza por ¿Qué lenguaje de programación aprender primero?.
FAQ
¿Cuál aprendo primero, PostgreSQL o MongoDB?
PostgreSQL. Los fundamentos de SQL —modelado relacional, JOINs, transacciones, índices— son transferibles a cualquier otro motor y te enseñan a pensar en estructura de datos. MongoDB tiene sentido después, cuando tengas un caso de uso concreto que se beneficia del modelo de documentos.
¿MySQL o PostgreSQL para un proyecto nuevo?
PostgreSQL en casi todos los casos de proyectos nuevos. Tiene mejor soporte de estándares SQL, extensiones más ricas (especialmente pgvector para IA y PostGIS para datos geoespaciales), y una comunidad open source más activa. MySQL sigue siendo la respuesta correcta si heredas un stack existente o usas hosting compartido donde MySQL es la única opción disponible.
¿SQLite sirve para algo serio o es solo para prototipos?
SQLite sirve para cosas muy serias. Es el motor de base de datos más desplegado del mundo —está en todos los teléfonos Android e iOS, en los navegadores, en muchas apps de escritorio. Para aplicaciones con un solo proceso de escritura concurrente (apps de escritorio, apps móviles, archivos de datos locales), es la elección correcta. Sus limitaciones son concurrencia alta de escrituras y escala horizontal, no calidad ni confiabilidad.
¿Vale la pena aprender SQL si voy a usar un ORM?
Sí, definitivamente. Los ORMs (Prisma, SQLAlchemy, TypeORM, ActiveRecord) generan SQL por ti, pero cuando el query generado es lento o incorrecto, necesitas saber SQL para entender qué está pasando y cómo corregirlo. Además, los ORMs tienen límites: consultas analíticas complejas o queries muy optimizados frecuentemente requieren SQL raw. El ORM es una herramienta de productividad, no un reemplazo del conocimiento.
¿Cuándo tiene sentido una base de datos de grafos como Neo4j?
Cuando las relaciones entre entidades son tan centrales al problema que la forma más natural de consultarlas es atravesar el grafo. Los casos clásicos: redes sociales (amigos de amigos, grados de separación), motores de recomendación (usuarios similares compraron X), detección de fraude (patrones de transacciones), gestión de dependencias. Para la mayoría de aplicaciones de negocio estándar, PostgreSQL con JOINs cubre el mismo territorio sin añadir otra tecnología al stack.
Fuentes
Las versiones y cambios de licencia mencionados se apoyan en las fuentes oficiales:
- MongoDB — Release Notes — MongoDB (versión 8.0 y parches)
- Redis — Redis (modelo de licencias desde Redis 8.0)