Bases de datos para tu aplicación: SQL vs NoSQL

La elección de la base de datos es una de las decisiones arquitectónicas más importantes en cualquier proyecto de software, y también una de las más difíciles de revertir una vez tomada. A diferencia de cambiar un framework o una librería, migrar de un sistema de base de datos a otro en una aplicación en producción con datos reales es una operación compleja, costosa y arriesgada. Por eso, invertir tiempo en entender bien las opciones disponibles antes de empezar es una de las mejores inversiones que puedes hacer como arquitecto o desarrollador senior.

El debate SQL vs NoSQL lleva más de quince años generando artículos, conferencias y discusiones acaloradas en equipos de desarrollo. La realidad es que ambos paradigmas tienen fortalezas genuinas y casos de uso donde brillan. La clave no es decidir cuál es mejor en abstracto —esa pregunta no tiene respuesta— sino entender qué características de cada uno se alinean mejor con los requisitos específicos de tu aplicación: el modelo de datos, los patrones de acceso, los requisitos de consistencia, la escala esperada y las capacidades del equipo.

En esta guía examinaremos los dos paradigmas en profundidad, exploraremos los representantes más importantes de cada familia (PostgreSQL, MySQL, MongoDB, Redis, Cassandra, Elasticsearch) y proporcionaremos un marco de decisión práctico con criterios concretos para elegir la base de datos adecuada para los escenarios más comunes en aplicaciones web empresariales.

Bases de datos relacionales (SQL): fundamentos

Las bases de datos relacionales almacenan datos en tablas con esquemas predefinidos y utilizan SQL (Structured Query Language) para consultar y manipular los datos. Fueron diseñadas en los años 70 por Edgar Codd basándose en la teoría matemática de conjuntos y álgebra relacional, y han demostrado ser extraordinariamente duraderas: siguen siendo la opción predeterminada para la mayoría de las aplicaciones empresariales décadas después de su invención.

Su fortaleza fundamental son las propiedades ACID: Atomicidad (una transacción se completa entera o no se completa), Consistencia (las transacciones llevan la base de datos de un estado válido a otro estado válido), Aislamiento (las transacciones concurrentes no se interfieren entre sí) y Durabilidad (los datos confirmados persisten incluso ante fallos del sistema). Estas garantías son cruciales para aplicaciones financieras, de gestión de inventario, sistemas de reservas o cualquier dominio donde la integridad de los datos es crítica.

PostgreSQL: la base de datos relacional para aplicaciones modernas

PostgreSQL es la base de datos relacional de código abierto más avanzada disponible hoy. Va mucho más allá del SQL estándar: soporte nativo para JSON y JSONB (con indexación), arrays, rangos, tipos geométricos, full-text search, extensiones como PostGIS para datos geoespaciales y TimescaleDB para series temporales, y una capacidad de indexación muy avanzada con índices GIN, GiST, BRIN y parciales. Para la mayoría de las aplicaciones web modernas, PostgreSQL puede manejar casos de uso que teóricamente requerirían una base de datos NoSQL especializada.

La columna JSONB de PostgreSQL merece especial atención: permite almacenar documentos JSON con esquema flexible junto a columnas relacionales tradicionales en la misma tabla, con indexación eficiente sobre campos del JSON y la posibilidad de hacer consultas complejas que combinan datos relacionales y documentales. Esto reduce significativamente la necesidad de añadir MongoDB u otra base de datos documental separada para casos de uso con esquema variable.

MySQL y MariaDB: madurez y ecosistema

MySQL sigue siendo la base de datos relacional más utilizada del mundo según muchas encuestas, especialmente en el mundo PHP y en aplicaciones legacy. MariaDB, su fork open source liderado por el fundador original de MySQL, ofrece mejoras de rendimiento y características adicionales manteniendo compatibilidad. Ambas son opciones sólidas con ecosistemas enormes, documentación extensísima y soporte robusto de todos los principales proveedores cloud. Para proyectos nuevos, PostgreSQL suele ser preferible por sus características más avanzadas, pero MySQL/MariaDB son excelentes elecciones si el equipo tiene experiencia con ellas.

Bases de datos NoSQL: tipos y casos de uso

NoSQL no es un único tipo de base de datos sino una familia diversa de sistemas que comparten la característica de no usar el modelo relacional. Esta diversidad es importante: una base de datos documental como MongoDB tiene muy poco en común con una base de datos columnar como Apache Cassandra o una base de datos de grafos como Neo4j, más allá de no ser relacionales. La elección dentro del mundo NoSQL depende tanto del modelo de datos como de los requisitos de acceso.

Bases de datos documentales: MongoDB y alternativas

MongoDB almacena datos como documentos BSON (una representación binaria de JSON), lo que permite esquemas flexibles donde cada documento puede tener una estructura diferente. Esta flexibilidad es genuinamente valiosa en las fases iniciales de un producto donde el modelo de datos evoluciona rápidamente, en sistemas de gestión de contenido con tipos de contenido muy variados o en aplicaciones que almacenan datos de terceros con estructuras variables. El modelo de documentos encaja naturalmente con el modelo de objetos de los lenguajes de programación orientados a objetos, reduciendo la impedancia objeto-relacional.

Las limitaciones de MongoDB son simétricas a sus fortalezas: las consultas que unen datos de múltiples colecciones (el equivalente a un JOIN SQL) son significativamente más costosas y menos elegantes que en bases de datos relacionales. La flexibilidad de esquema, si no se gestiona con disciplina, puede convertirse en un problema de calidad de datos donde diferentes documentos usan nombres de campo inconsistentes, tipos diferentes para el mismo campo o estructuras anidadas caóticas. En la práctica, los equipos que usan MongoDB acaban definiendo esquemas explícitos con librerías como Mongoose, recuperando parte del rigor relacional.

Redis: la navaja suiza del almacenamiento en memoria

Redis es una base de datos en memoria que soporta múltiples estructuras de datos: strings, hashes, listas, conjuntos, conjuntos ordenados, streams y más. Su velocidad es excepcional —puede manejar millones de operaciones por segundo— y lo convierte en la herramienta ideal para casos de uso específicos donde la latencia ultra-baja es crítica. El caché de resultados de consultas costosas, el almacenamiento de sesiones de usuario, las colas de trabajos, los rankings en tiempo real (con sorted sets), el pub/sub para mensajería y el rate limiting son los casos de uso más comunes.

Redis no es un reemplazo para tu base de datos principal sino un complemento. Sus datos principales están en memoria (aunque tiene persistencia opcional en disco), lo que lo hace muy rápido pero también más costoso por gigabyte almacenado comparado con opciones en disco. Para aplicaciones que necesitan un simple caché de consultas o sesiones de usuario, Redis es prácticamente insustituible. Redis Cluster permite distribuir los datos horizontalmente cuando el dataset crece más allá de la capacidad de una sola máquina.

Cassandra: escalabilidad horizontal extrema

Apache Cassandra es una base de datos columnar distribuida diseñada para manejar cantidades masivas de datos distribuidos a través de muchos servidores sin un único punto de fallo. Su arquitectura peer-to-peer (sin nodo maestro) le permite escalar linealmente añadiendo nodos: doblar los nodos dobla aproximadamente el throughput. Es la elección de Netflix, Apple y Discord para casos de uso con escrituras masivas distribuidas globalmente y consultas de baja latencia a escala de miles de millones de registros.

Cassandra tiene limitaciones importantes que hacen que no sea adecuada para la mayoría de aplicaciones de tamaño medio. Su modelo de datos está optimizado para patrones de acceso específicos: debes diseñar las tablas en función de las consultas que vas a hacer, no en función de las relaciones entre los datos. Las consultas ad-hoc y los JOINs no existen. Las transacciones ACID multi-fila son limitadas. Cassandra brilla en casos de uso muy específicos con escala masiva; para aplicaciones web convencionales, es una complejidad innecesaria.

Elasticsearch: búsqueda y analítica de texto completo

Elasticsearch es técnicamente una base de datos documental, pero su fortaleza única es la búsqueda de texto completo y la analítica sobre grandes volúmenes de datos semiestructurados. Construido sobre Apache Lucene, ofrece capacidades de búsqueda que ninguna base de datos relacional puede igualar: búsqueda por relevancia con scoring, búsqueda por campos de texto con soporte de sinónimos, stemming y fuzziness, agregaciones analíticas sobre millones de documentos en milisegundos y visualización con Kibana.

Elasticsearch generalmente se usa como complemento, no como base de datos principal. El patrón típico es almacenar los datos autoritativos en PostgreSQL u otra base de datos relacional y sincronizar un subconjunto de los datos a Elasticsearch para habilitar las búsquedas. Herramientas como Debezium permiten esta sincronización usando Change Data Capture (CDC) de forma fiable. Para aplicaciones con un buscador prominente —e-commerce, portales de empleo, directorios de empresas— esta arquitectura híbrida es la más común.

Criterios para elegir la base de datos correcta

En lugar de elegir una base de datos basándose en tendencias tecnológicas o en lo que usa la startup más mencionada en Hacker News, conviene aplicar un marco de decisión basado en los requisitos reales del proyecto. Los criterios más relevantes son: la naturaleza del modelo de datos, los patrones de acceso principales, los requisitos de consistencia y transaccionalidad, la escala esperada en los próximos dos o tres años, y las capacidades operativas del equipo.

• Modelo de datos altamente relacional con muchas entidades interconectadas: SQL (PostgreSQL). Las relaciones y los JOINs son ciudadanos de primera clase.
• Esquema muy variable o datos de documentos con estructura inconsistente: MongoDB o PostgreSQL con JSONB si las relaciones son importantes.
• Escala masiva con millones de escrituras por segundo distribuidas globalmente: Cassandra o DynamoDB.
• Búsqueda de texto completo sobre grandes volúmenes de datos: Elasticsearch como complemento a la base de datos principal.
• Caché de alta velocidad, sesiones, colas de trabajos, rankings en tiempo real: Redis.
• Datos con relaciones complejas tipo grafo (redes sociales, motores de recomendación, detección de fraude): Neo4j u otras bases de datos de grafos.
• Series temporales (métricas, logs, datos de sensores IoT): TimescaleDB (extensión de PostgreSQL) o InfluxDB.

La trampa de la complejidad: empieza con lo simple

Uno de los errores más comunes en equipos de desarrollo es adoptar múltiples bases de datos especializadas desde el principio del proyecto siguiendo el principio de elegir siempre la herramienta más adecuada para cada caso de uso. En la práctica, cada base de datos adicional en tu stack es una carga operativa real: hay que configurarla, securizarla, monitorizar su salud, gestionar backups, documentar el modelo de datos y entrenar al equipo en su uso. Para un equipo pequeño construyendo un MVP, esta complejidad puede ser fatal.

La recomendación pragmática para la mayoría de las aplicaciones web es empezar con una sola base de datos relacional —PostgreSQL es la elección por defecto— y añadir Redis cuando tengas una necesidad concreta de caché o colas. Antes de añadir una base de datos especializada, agota las capacidades de PostgreSQL: full-text search nativo, JSONB para datos semiestructurados, TimescaleDB para series temporales. Solo cuando tengas evidencia de que PostgreSQL no puede satisfacer un requisito específico debería plantearse añadir otra base de datos al stack.

ORM y acceso a datos: Prisma, TypeORM y alternativas

Un ORM (Object-Relational Mapper) traduce entre el modelo orientado a objetos de tu código y el modelo relacional de la base de datos, generando SQL automáticamente y mapeando los resultados a objetos. En el ecosistema Node.js/TypeScript, Prisma se ha convertido en la opción dominante por su excelente integración con TypeScript (tipos generados automáticamente a partir del esquema), su interfaz de consultas expresiva y su sistema de migraciones declarativo. TypeORM es una alternativa madura con más características pero con una API más compleja.

Los ORM tienen sus críticos: el SQL generado automáticamente puede ser ineficiente, especialmente en consultas complejas; la abstracción puede ocultar problemas de rendimiento (el infame N+1 problem); y aprender las peculiaridades del ORM añade una capa de complejidad. Para muchos casos de uso, son sin embargo la opción correcta por la productividad que ofrecen. El enfoque pragmático es usar el ORM para el 90% de las consultas y caer a SQL crudo (que Prisma también soporta) para las consultas complejas donde el control total es necesario.

Backup, recuperación y alta disponibilidad

Los datos son el activo más valioso de cualquier aplicación y su pérdida puede ser catastrófica. Una estrategia de backup robusta no es opcional. Para PostgreSQL, pg_dump produce backups lógicos útiles para migraciones y backups puntuales; pg_basebackup produce backups físicos más rápidos de restaurar para bases de datos grandes; y las herramientas de WAL archiving como Barman o pgBackRest permiten Point-in-Time Recovery (PITR), la capacidad de restaurar la base de datos a cualquier momento en el pasado, no solo al último backup completo.

La alta disponibilidad se implementa con réplicas de lectura y un sistema de failover automático. En entornos cloud, servicios gestionados como Amazon RDS, Google Cloud SQL o Azure Database for PostgreSQL incluyen alta disponibilidad con réplica síncrona y failover automático, simplificando enormemente la operación. Para bases de datos on-premise, Patroni es la solución más popular para gestionar clústeres PostgreSQL con failover automático. Define siempre un Recovery Time Objective (RTO) y un Recovery Point Objective (RPO) para tu aplicación antes de diseñar la estrategia de disponibilidad.

Rendimiento: indexación e optimización de consultas

Los problemas de rendimiento de base de datos en aplicaciones web son casi siempre el resultado de índices faltantes o consultas mal escritas, no de limitaciones de la base de datos en sí. Un índice sobre la columna correcta puede transformar una consulta que tarda 10 segundos en una que tarda 1 milisegundo. La herramienta EXPLAIN ANALYZE de PostgreSQL muestra el plan de ejecución de cualquier consulta, revelando si usa índices o hace sequential scans sobre millones de filas.

El N+1 query problem es el anti-patrón de rendimiento más común en aplicaciones que usan ORMs: en lugar de obtener todos los datos necesarios en una consulta con JOINs, el código hace una consulta para obtener la lista de N elementos y luego N consultas adicionales para obtener los datos relacionados de cada elemento. El resultado son N+1 consultas en lugar de una o dos, con un impacto de rendimiento devastador a medida que N crece. Los ORM modernos permiten resolver esto con eager loading o joins explícitos; entender cuándo y cómo usarlos es una habilidad esencial.

La base de datos correcta no es la más moderna ni la que usa la empresa más famosa: es la que mejor encaja con tu modelo de datos, tus patrones de acceso y las capacidades de tu equipo. PostgreSQL resuelve el 90% de los casos de uso de aplicaciones web modernas con elegancia y fiabilidad probada.