Módulo 8 · Bases de datos/Lección 49
Elegir una base de datos
Relacional o NoSQL, en tu propio servidor o administrada. Las preguntas que deciden.
Casi toda aplicación guarda datos que cambian: usuarios, pedidos, inventario, mensajes. Para eso existe la base de datos. La pregunta no es si usar una, sino cuál: hay bases que piensan en tablas relacionadas y otras que piensan en llaves, documentos o conexiones. Y hay que decidir si la administras tú o AWS.
AWS defiende la idea de las bases de datos de propósito específico (purpose-built): en lugar de forzar todo en un solo motor, eliges el que mejor encaja con cada tipo de dato y de consulta.
Relacional
Los datos viven en tablas con columnas fijas (el esquema). Las tablas se relacionan con llaves: el pedido tiene el cliente_id del cliente que lo hizo. Se consultan con SQL, que permite cruzar tablas (joins), filtrar, agrupar y sumar de cualquier forma, incluso con preguntas que no pensaste al diseñar.
Las bases relacionales garantizan transacciones: si una operación cambia varias filas, se aplican todas o ninguna. Por eso son la elección natural para dinero, inventario y todo lo que deba cuadrar. Ejemplos: MySQL, PostgreSQL, SQL Server, Oracle. En AWS: Amazon RDS y Amazon Aurora.
NoSQL y las bases especializadas
«NoSQL» agrupa bases que no usan el modelo de tablas relacionadas. Cambian flexibilidad de consulta por escala, velocidad o un modelo de datos que encaja mejor con el problema. Cada familia tiene su servicio en AWS:
Para analizar grandes volúmenes de datos históricos (no para la operación diaria) existe además un almacén de datos, Amazon Redshift, que se ve en Datos y analítica.
En tu propia instancia o administrada
Puedes instalar PostgreSQL en una instancia EC2. Funciona, pero te quedas con todo el trabajo de operación. Con un servicio administrado como RDS, AWS hace la mayor parte. Esta tabla sigue la de la documentación oficial de RDS:
| Criterio |  Base en EC2 |  Amazon RDS |
|---|---|---|
| Hardware, energía y red física | AWS | AWS |
| Instalar y parchar el sistema operativo | Tú | AWS |
| Instalar y parchar el motor de base de datos | Tú | AWS |
| Respaldos | Tú | AWS (automáticos) |
| Alta disponibilidad | Tú montas la réplica y el failover | AWS, con un clic (Multi-AZ) |
| Escalar | Tú | AWS |
| Diseño, consultas y optimización | Tú | Tú |
| Acceso al sistema operativo | Total | No |
La base en EC2 tiene sentido cuando necesitas algo que el servicio administrado no ofrece: un motor o una versión que no soporta, acceso al sistema operativo o una configuración muy particular. Para todo lo demás, la recomendación de AWS es empezar por el servicio administrado. Es el modelo de responsabilidad compartida en acción: cuanto más administrado el servicio, menos capas te tocan.
Las preguntas que deciden
- 1
¿Los datos tienen relaciones y deben cuadrar?
Pedidos, pagos, inventario con reportes cruzados → relacional (RDS o Aurora). - 2
¿Siempre buscas por una llave y necesitas escala enorme?
Millones de usuarios que leen su perfil o su carrito → DynamoDB. - 3
¿El dato es un documento JSON que cambia de forma?
DynamoDB o DocumentDB, si ya usas MongoDB. - 4
¿Lo importante son las conexiones entre cosas?
Amigos de amigos, rutas, detección de fraude → Neptune. - 5
¿Lees lo mismo muchísimas veces?
Pon una caché delante con ElastiCache. - 6
¿Quieres administrar servidores?
Si la respuesta es no (casi siempre), elige un servicio administrado.
Quiz
Pon a prueba lo que aprendiste
0 de 4 correctas · 4 sin responder
1.Una empresa quiere una base relacional y reducir al mínimo el tiempo que dedica a parches y respaldos. ¿Qué elige?
2.Con Amazon RDS, ¿qué sigue siendo responsabilidad del cliente?
3.Una red social quiere encontrar «amigos de amigos» y relaciones entre millones de usuarios. ¿Qué base es la adecuada?
4.¿Cuándo tiene sentido instalar la base de datos en una instancia EC2 en lugar de usar RDS?