Amazon DynamoDB es la base de datos NoSQL serverless de AWS: un almacén distribuido y totalmente administrado, diseñado para responder en milisegundos de un solo dígito a cualquier escala. Soporta modelos de datos de clave-valor y de documentos, y está pensado para las cargas operativas que sostienen el día a día de una aplicación.
Dicho simple: es la base que se elige cuando el negocio necesita que la respuesta sea igual de rápida con diez mil usuarios que con diez millones, y sin un equipo dedicado a operar servidores de base de datos.
¿Qué problema resuelve DynamoDB?
Muchas aplicaciones crecen hasta un punto donde la base de datos deja de acompañar. El tráfico se vuelve difícil de predecir, las campañas generan picos de pocas horas, y sostener el rendimiento exige dimensionar servidores, planificar ventanas de mantenimiento y anticipar cuánta capacidad hará falta el próximo trimestre.
DynamoDB fue construido justamente para salir de esa conversación. AWS se encarga de la configuración, el mantenimiento, la alta disponibilidad, el aprovisionamiento de hardware, la seguridad y las copias de seguridad. No hay versiones mayores ni menores que actualizar ni ventanas de mantenimiento que coordinar: la tabla queda lista para producción desde que se crea.
Para el negocio eso se traduce en dos cosas concretas. La primera es previsibilidad: el tiempo de respuesta se mantiene estable aunque el volumen se multiplique. La segunda es que el equipo técnico dedica su tiempo al producto en lugar de a sostener infraestructura.
¿Cómo funciona DynamoDB?
Tres decisiones de diseño explican su comportamiento:
- Serverless de verdad: no hay servidores que aprovisionar, parchar ni administrar. DynamoDB ofrece dos modos de capacidad. En el modo bajo demanda la capacidad se ajusta de forma instantánea al tráfico y baja hasta cero cuando la tabla no recibe solicitudes, sin arranques en frío; en el modo aprovisionado el equipo define la capacidad de lectura y escritura por adelantado, lo que conviene cuando la carga es estable y predecible.
- Modelo NoSQL orientado al patrón de acceso: DynamoDB no admite la operación JOIN. La recomendación de AWS es denormalizar el modelo para reducir viajes a la base y el procesamiento necesario para responder. El diseño parte de las preguntas que la aplicación va a hacer, no de la estructura teórica de los datos.
- Distribución nativa: los datos se replican de forma predeterminada en tres zonas de disponibilidad, lo que sostiene la durabilidad y la disponibilidad sin trabajo adicional del equipo.
Esa combinación es la que permite que el rendimiento se mantenga constante mientras la tabla crece: no hay un límite práctico al tamaño de una tabla, ni en cantidad de elementos ni en bytes.
Capacidades que suelen decidir la conversación
| Capacidad | Qué resuelve |
|---|---|
| Tablas globales | Replicación multiactiva entre regiones, sin tabla principal ni conmutación por error que ejecutar |
| Transacciones ACID | Cambios coordinados de todo o nada sobre uno o varios elementos, dentro de una tabla o entre varias |
| DynamoDB Streams | Registro ordenado en el tiempo de cada cambio, para arquitecturas dirigidas por eventos |
| Índices secundarios | Consultas por atributos distintos de la clave principal, con índices locales y globales |
| Recuperación a un punto en el tiempo | Restauración con granularidad de segundos dentro de un período configurable de 1 a 35 días |
| DynamoDB Accelerator (DAX) | Caché en memoria administrada que lleva la respuesta de milisegundos a microsegundos |
Sobre los índices conviene tener presente el orden de magnitud: se pueden definir hasta 5 índices secundarios locales por tabla y la cuota predeterminada es de 20 índices secundarios globales por tabla.
Cómo se integra DynamoDB en una arquitectura AWS
DynamoDB rara vez trabaja aislado. Es la capa de datos operativa de aplicaciones modernas, y se conecta de forma nativa con el resto del ecosistema:
- AWS Lambda: permite crear disparadores que ejecutan código automáticamente ante cada cambio registrado en DynamoDB Streams. Es la base de las arquitecturas dirigidas por eventos.
- Amazon API Gateway y AWS AppSync: exponen los datos como API REST o GraphQL sin servidores intermedios que operar. Lo desarrollamos en la guía de REST frente a GraphQL.
- Amazon S3: importación y exportación de tablas completas o incrementales, para analítica y machine learning.
- Integración sin ETL con Amazon Redshift y Amazon OpenSearch Service: permite correr analítica compleja y búsqueda avanzada sobre los datos de la tabla, sin impacto sobre la carga productiva.
Ese último punto merece atención: la integración sin ETL evita construir y mantener las canalizaciones de ETL que tradicionalmente hacían falta para llevar datos operativos al almacén analítico.
Seguridad y cumplimiento
DynamoDB cifra todos los datos en reposo de forma predeterminada, con llaves administradas en AWS Key Management Service. El acceso se controla con AWS Identity and Access Management, lo que elimina usuarios y contraseñas propios de la base de datos y con ello las políticas de rotación asociadas. IAM también permite control de acceso detallado a nivel de atributo.
En materia de cumplimiento, DynamoDB se adhiere a estándares como HIPAA, PCI DSS y GDPR, un punto relevante para las organizaciones de servicios financieros y de salud que operan bajo requisitos regulatorios.
¿DynamoDB o una base relacional?
Es la pregunta que más aparece, y la respuesta honesta es que no es excluyente. La mayoría de las arquitecturas maduras combinan ambas: una base relacional para el núcleo transaccional con muchas relaciones, y DynamoDB para catálogos, sesiones, perfiles y eventos de alto volumen.
La lectura práctica es esta. Cuando los patrones de acceso son conocidos y el requisito es latencia constante a gran escala, DynamoDB encaja. Cuando las consultas son exploratorias, cambiantes y se apoyan en recorrer relaciones, conviene una base relacional como las que se operan sobre Amazon RDS o Amazon Aurora. Si quieres profundizar en el lado relacional, revisa la comparativa entre PostgreSQL y MySQL.
DynamoDB dentro de una estrategia de datos
Adoptar DynamoDB es una decisión de arquitectura, no una elección de herramienta. Rinde cuando el modelo de datos se diseña alrededor de los patrones de acceso reales de la aplicación, y decepciona cuando se lo trata como una base relacional sin esquema. Esa diferencia se define en el diseño, antes de la primera línea de código.
En Caleidos diseñamos e implementamos estas arquitecturas dentro de nuestras prácticas de aplicaciones cloud-native y Data Engineering en AWS, y las sostenemos con Caleidos Lens©, nuestra mesa de servicio 24×7. Puedes ver cómo lo aplicamos en nuestros casos de éxito.
Preguntas frecuentes
¿Qué es DynamoDB en términos simples? La base NoSQL serverless de AWS: totalmente administrada, distribuida y con respuesta en milisegundos de un solo dígito a cualquier escala.
¿Reemplaza a una base relacional? No necesariamente. Conviene cuando los patrones de acceso son conocidos y el requisito es escala con latencia constante; lo relacional sigue siendo mejor para consultas exploratorias y modelos con muchas relaciones.
¿Cómo se recupera ante un incidente? Con copias continuas que permiten restaurar a cualquier segundo dentro de un período configurable de 1 a 35 días, copias bajo demanda para retención larga y tablas globales para resiliencia multi-región.
¿Evalúas DynamoDB para tu aplicación?
Conversemos sobre tu caso y te damos una lectura concreta de si tu carga encaja mejor en DynamoDB, en una base relacional, o en una arquitectura que combine ambas.
