Hemos visto varias opciones para guardar datos: RDS/Aurora (relacional), DynamoDB (NoSQL) y ElastiCache (caché). Y AWS tiene aún más. Ante tanta variedad, surge la pregunta clave: ¿cuál uso para mi caso? Este subcapítulo te da el criterio para elegir bien. Cierra la Parte II y es uno de los conocimientos más prácticos del libro.

AWS defiende la idea de bases de datos especializadas (purpose-built): en lugar de forzar todos tus datos en un único tipo de base de datos, eliges el tipo que mejor encaja con cada necesidad. Una aplicación grande a menudo usa varias bases de datos distintas a la vez, cada una para lo que mejor hace.

Analogía: No usas un martillo para todo. Para clavar usas un martillo; para atornillar, un destornillador; para cortar, una sierra. Con las bases de datos igual: cada tipo es la herramienta ideal para cierto trabajo.

Hazte estas preguntas sobre tus datos y tu caso:

1. ¿Mis datos tienen una estructura clara y relaciones entre sí?
2. ¿Necesito consultas complejas (filtros, joins, informes)?
3. ¿Qué escala y rendimiento necesito?
4. ¿Los datos cambian de forma flexible o tienen un esquema fijo?
5. ¿Estoy repitiendo muchas lecturas iguales?

Veamos cómo te orientan hacia cada opción.

• Tus datos tienen estructura clara y relaciones (usuarios que tienen pedidos, pedidos que tienen productos…).
• Necesitas consultas complejas: filtros múltiples, uniones entre tablas, informes, agregaciones.
• La consistencia y la integridad de los datos son críticas (banca, facturación, inventario).
• Tu aplicación usa SQL.

Ejemplos: sistemas de gestión, banca, facturación, comercio electrónico (la parte de pedidos), aplicaciones empresariales clásicas. Aurora si necesitas más rendimiento/escala; RDS vanilla si quieres algo más sencillo y económico.

• Necesitas escala masiva y rendimiento constante en milisegundos.
• Accedes a los datos sobre todo por una clave conocida («dame el elemento X»).
• Tus datos son flexibles o cambian de estructura con frecuencia.
• Quieres cero administración (serverless).

Ejemplos: carritos de compra, perfiles de usuario, sesiones, catálogos con atributos variables, datos de IoT, aplicaciones con millones de usuarios y picos enormes.

• Repites muchas lecturas iguales y quieres acelerarlas.
• Quieres aliviar la carga de tu base de datos principal.
• Necesitas datos «calientes» al instante (sesiones, rankings, contadores).

Recuerda: la caché acompaña a otra base de datos; no la sustituye. Es una capa de velocidad por delante.

Las tres últimas filas son bases especializadas que AWS también ofrece. No las hemos detallado, pero conviene saber que existen para casos concretos (veremos Redshift en el Capítulo 29).

En la vida real, una aplicación seria mezcla varias. Veamos un ejemplo completo.

Ejemplo real — una tienda online:

• RDS/Aurora (relacional): guarda los pedidos, pagos y facturas, donde la consistencia y las relaciones son críticas. Aquí necesitas SQL y garantías fuertes.
• DynamoDB (NoSQL): guarda los carritos de la compra y las sesiones, que requieren escala enorme y acceso rápido por id de usuario.
• ElastiCache (caché): guarda el catálogo de productos más visitados para que las páginas carguen al instante sin machacar la base de datos.
• OpenSearch: alimenta el buscador de productos con búsquedas de texto avanzadas.

Cada pieza usa la base de datos que mejor resuelve su problema. Forzar todo en una sola haría la aplicación más lenta, más cara o más frágil.

No te abrumes con tantas opciones. Cuando empiezas:

Si tienes dudas, una base de datos relacional (RDS/Aurora) es casi siempre una elección segura y versátil. Cubre la mayoría de necesidades. Añade DynamoDB cuando tengas un caso claro de escala masiva o acceso por clave, y ElastiCache cuando notes que la base de datos sufre por lecturas repetidas. Empieza simple y especializa solo cuando lo necesites.

• AWS promueve bases de datos especializadas: elige el tipo que mejor encaja con cada necesidad, en lugar de forzar todo en una sola.
• Relacional (RDS/Aurora): estructura, relaciones, consultas complejas, consistencia (SQL).
• NoSQL (DynamoDB): escala masiva, rendimiento constante, acceso por clave, flexibilidad.
• Caché (ElastiCache): acelerar lecturas repetidas y aliviar la base de datos (siempre acompañando a otra).
• Las aplicaciones serias combinan varias según cada problema.
• Si dudas al empezar, una base relacional es la opción segura y versátil; especializa cuando surja la necesidad.

Con esto cierras el Capítulo 8 y la Parte II. Ya conoces los servicios esenciales de AWS: cómputo (EC2), almacenamiento (S3), redes (VPC), identidad (IAM) y bases de datos. En la Parte III damos un gran salto: aprenderemos a definir toda esta infraestructura como código con Terraform.