Existen dos grandes familias de bases de datos: las relacionales y las no relacionales, y elegir la equivocada puede costarle a una empresa millones de pesos en ineficiencia.
Era martes por la noche en la Ciudad de México. Daniela, coordinadora de tecnología en una tienda de comercio electrónico del Estado de México, recibió una alerta: el sistema tardaba 40 segundos en cargar el perfil de cada usuario durante el Buen Fin. Los clientes abandonaban su carrito. Las ventas caían en tiempo real. Daniela sabía que algo estaba mal, pero no podía explicar exactamente qué. La respuesta estaba en una decisión que nadie había cuestionado meses atrás: el tipo de base de datos que usaba su plataforma.
Las dos grandes familias
Antes de entender qué falló esa noche, necesitas conocer el terreno. Las bases de datos no son todas iguales. Se dividen en dos categorías principales según la forma en que organizan y almacenan la información.
Las bases de datos relacionales guardan la información en tablas con filas y columnas, como aprendiste en la lección anterior. Cada tabla tiene una estructura fija: defines las columnas de antemano y cada registro debe respetar ese formato. Estas bases de datos usan un lenguaje llamado SQL para consultar y manipular los datos. Por eso también se les llama bases de datos SQL.
Las bases de datos no relacionales, conocidas como NoSQL, funcionan de manera distinta. No usan tablas rígidas. En cambio, almacenan la información en formatos más flexibles: documentos, pares clave-valor, grafos o columnas anchas. Puedes guardar registros con campos completamente diferentes entre sí sin que el sistema proteste.
Estas dos familias no compiten directamente: cada una existe porque resuelve un problema específico mejor que la otra.
Cómo funcionan las bases de datos relacionales
Imagina que Bimbo necesita registrar cada pedido de sus distribuidores en toda la República Mexicana. Cada pedido tiene: un identificador, la fecha, el nombre del distribuidor, los productos solicitados y el monto total. Esa estructura es siempre la misma. No importa si el pedido viene de Monterrey o de Oaxaca: los campos no cambian.
Eso es exactamente para lo que nacieron las bases de datos relacionales. Son ideales cuando los datos tienen una estructura predecible y estable. También brillan cuando necesitas relacionar tablas entre sí. Por ejemplo, la tabla de pedidos se conecta con la tabla de distribuidores mediante un identificador compartido. Así evitas repetir el nombre y la dirección del distribuidor en cada pedido.
Algunos sistemas de bases de datos relacionales muy usados en México son MySQL, PostgreSQL y Microsoft SQL Server. El SAT, por ejemplo, usa bases de datos relacionales para manejar las declaraciones fiscales de millones de contribuyentes. La estructura es tan rígida y regulada que un sistema flexible sería más un problema que una solución.
La gran fortaleza de las bases de datos relacionales es la consistencia. Cuando registras una venta en el sistema del IMSS, necesitas la certeza absoluta de que ese dato no se va a corromper, duplicar ni perder. Las bases de datos relacionales garantizan esto mediante reglas estrictas llamadas transacciones.
Cómo funcionan las bases de datos no relacionales
Ahora imagina el perfil de un usuario en Mercado Libre. Un usuario tiene nombre, correo y teléfono. Hasta ahí, todo igual. Pero también tiene un historial de búsquedas, listas de deseos, reseñas escritas, métodos de pago guardados, direcciones de envío y preferencias de notificación. Cada usuario puede tener un número diferente de direcciones, de tarjetas y de reseñas. No hay dos perfiles exactamente iguales.
Forzar esa información en tablas rígidas sería como intentar guardar ropa de todas las tallas en cajas del mismo tamaño. Podrías hacerlo, pero desperdiciarías mucho espacio y tiempo. Las bases de datos no relacionales resuelven este problema.
En una base de datos de documentos como MongoDB, el perfil de cada usuario se guarda como un documento independiente que puede tener los campos que necesite. Si un usuario tiene 3 direcciones y otro tiene 7, el sistema no necesita crear columnas vacías para ninguno de los dos.
Otro tipo muy popular es el de pares clave-valor, donde cada dato se guarda con una etiqueta única. Redis es el más conocido. Lo usan empresas como Liverpool para guardar los resultados de búsquedas frecuentes en memoria, de modo que no tienen que ir a consultar la base de datos principal cada vez que alguien busca "tenis Nike talla 27". Eso reduce el tiempo de respuesta de segundos a milisegundos.
Según reportes de la industria tecnológica en América Latina, el 68% de las aplicaciones de alto tráfico en la región combinan al menos dos tipos de bases de datos distintas para aprovechar lo mejor de cada una.
¿Cuándo usar cada tipo?
Esta es la pregunta que más confunde a quienes empiezan. La respuesta no es complicada si piensas en el tipo de dato que vas a manejar.
Usa una base de datos relacional cuando:
Tus datos tienen siempre la misma estructura. Las relaciones entre tablas son importantes y frecuentes. La integridad y consistencia son críticas, como en sistemas financieros, nómina o declaraciones fiscales. Un ejemplo claro es el sistema de facturación electrónica que exige el SAT: cada campo del CFDI tiene un formato exacto y obligatorio. No hay margen para la flexibilidad.
Usa una base de datos no relacional cuando:
Tus datos cambian de forma con frecuencia o son difíciles de estructurar en tablas. Necesitas escalar rápidamente para manejar millones de usuarios simultáneos. Trabajas con contenido multimedia, redes sociales o datos en tiempo real. Una app de delivery como Rappi o una plataforma de streaming necesita responder a cientos de miles de usuarios al mismo tiempo. Las bases de datos NoSQL escalan mejor horizontalmente: puedes agregar más servidores sin rediseñar toda la arquitectura.
El error que cometió el equipo de Daniela
Volvamos a esa noche de Buen Fin en el Estado de México. El equipo de Daniela había elegido una base de datos relacional para manejar el catálogo de productos. En condiciones normales, funcionaba perfectamente. Pero durante el Buen Fin, el tráfico se multiplicó por 15 en cuestión de horas. El sistema tenía que unir cinco tablas diferentes para mostrar un solo producto: categoría, inventario, precio, imágenes y reseñas.
Cada consulta tardaba demasiado. Con 10 usuarios simultáneos, no se notaba. Con 80,000 usuarios al mismo tiempo, el sistema colapsó.
La solución no fue eliminar la base de datos relacional. Fue agregar una capa de base de datos NoSQL tipo clave-valor para guardar temporalmente los productos más visitados. El catálogo completo siguió en la base de datos relacional. Pero los 200 productos más buscados vivían en Redis, listos para responder en menos de un milisegundo.
Esa combinación redujo los tiempos de carga de 40 segundos a menos de 2 segundos. Las ventas se recuperaron esa misma noche.
Relacionales vs. No relacionales: una comparación directa
| Característica | Relacional (SQL) | No relacional (NoSQL) |
|---|---|---|
| Estructura de datos | Tablas fijas | Flexible (documentos, clave-valor) |
| Lenguaje principal | SQL | Varía por sistema |
| Escalabilidad | Vertical (más potencia al servidor) | Horizontal (más servidores) |
| Consistencia | Muy alta | Depende del sistema |
| Ideal para | Finanzas, nómina, inventario | Redes sociales, catálogos, caché |
| Ejemplos en México | SAT, IMSS, bancos | Mercado Libre, apps de delivery |
No existe un tipo superior al otro. Existen herramientas distintas para problemas distintos. Un arquitecto de bases de datos experimentado sabe usar ambas en el mismo proyecto, tal como lo demostró el equipo de Daniela esa noche de Buen Fin.
En la siguiente lección vas a explorar SQL con más detalle: el lenguaje que le habla directamente a las bases de datos relacionales y que te permite crear, consultar y modificar información con precisión quirúrgica.