Llevo varios años trabajando con AWS y si me preguntan cuál fue el servicio que más me costó “entender de verdad”, sin dudarlo digo DynamoDB.

No porque sea complicado de usar (de hecho crear una tabla toma como 30 segundos), sino porque uno viene con la cabeza llena de SQL y termina queriendo hacer cosas que en DynamoDB simplemente no se hacen así.

Este post es una introducción nivel 100. La idea es que si nunca has tocado DynamoDB, salgas con una imagen clara de qué es, cuándo conviene usarlo y, sobre todo, los conceptos mínimos para no pegarte contra la pared como me pasó a mí la primera vez.

¿Qué es DynamoDB? (la versión sin marketing)

DynamoDB es la base de datos NoSQL administrada de AWS. Punto.

Es key-value y documental al mismo tiempo, serverless de verdad (no hay instancias que aprovisionar, no hay parches, no hay nada), y está diseñada para escalar a niveles que la mayoría de nosotros nunca vamos a necesitar.

Lo importante: no es un reemplazo de PostgreSQL ni de MySQL. Es otra cosa.

Y ahí es donde mucha gente se confunde, yo el primero.

Cuando recién empecé, intenté modelar todo como si fuera relacional:

• tabla de usuarios
• tabla de pedidos
• tabla de productos

Y cuando quise hacer un join… bueno, no existe el join.

El problema no era DynamoDB, era cómo lo estaba pensando.

Cuándo sí, cuándo no

Antes de usar DynamoDB, hazte esta pregunta.

Tiene sentido cuando:

• Tu carga es principalmente por clave (lookups por ID)
• Necesitas latencias de milisegundos consistentes
• Tienes access patterns claros
• Esperas escalar mucho o tener picos impredecibles
• No quieres administrar infraestructura

Probablemente no es lo ideal cuando:

• Necesitas queries ad-hoc o exploratorios
• Requieres joins complejos
• Haces reportes o analítica pesada
• No puedes definir access patterns desde el inicio

Para analítica, puedes complementar con S3 + Athena o Redshift.

Conceptos mínimos que debes manejar

Tabla, item, atributo

• Tabla → colección de datos
• Item → fila
• Atributo → columna

No todos los items tienen los mismos atributos.

La Primary Key (aquí se juega todo)

Dos tipos:

• Partition Key
• Partition Key + Sort Key

La Partition Key:

• Determina dónde vive el dato
• Si la eliges mal → hot partitions

La Sort Key:

• Permite múltiples registros por Partition Key
• Habilita patrones avanzados

Capacity: On-Demand vs Provisioned

• On-Demand → pagas por uso
• Provisioned → defines capacidad

Regla práctica: empieza con On-Demand.

Single-table design: el cambio mental

En DynamoDB:

No modelas entidades, modelas access patterns.

Ejemplo:

PK              | SK              | atributos
USER#123        | PROFILE         | nombre, email
USER#123        | ORDER#001       | total, fecha
USER#123        | ORDER#002       | total, fecha

Con un solo query traes perfil y pedidos.

Query vs Scan

• Query → eficiente
• Scan → lee toda la tabla

Regla de oro: evita Scan en producción.

GSI y LSI

• GSI → nuevas formas de consultar
• LSI → misma PK, distinta SK

Cada índice cuesta dinero, no crees de más.

Buenas prácticas

• Define access patterns antes
• Usa TTL para datos temporales
• Evita items grandes (>400KB)
• Usa IAM correctamente
• Usa Streams + Lambda
• Activa backups (PITR)

Errores comunes

• Usar DynamoDB como SQL
• Hacer Scan en producción
• Crear demasiados GSI
• Provisionar demasiado pronto
• Mal diseño de Partition Key

DynamoDB no es mejor ni peor que una base relacional.

Es una herramienta distinta.

Cuando se diseña bien:

• performance alto
• escalabilidad real
• operación simple

Mi consejo:

• empieza pequeño
• define access patterns en papel
• equivócate pero nunca te rindas

Nos leemos en el siguiente post 🚀