¿Cómo de rápido es DynamoDB?
Rápido. DynamoDB ofrece una latencia constante de lectura y escritura de milisegundos de un solo dígito a cualquier escala. Añadir DynamoDB Accelerator (DAX), una caché en memoria, baja las lecturas eventualmente consistentes a microsegundos. El rendimiento se mantiene plano según crecen las tablas porque las lecturas van directas a una clave de partición en lugar de escanear, así que la latencia no se degrada con el volumen de datos.
Por qué sigue siendo rápido a escala
Un GetItem o una Query calculan el hash de la clave de partición y van directos a la partición física correcta. Nunca escanean la tabla entera, así que el tiempo de respuesta es aproximadamente constante tanto si la tabla tiene miles de Items como si tiene miles de millones.
Lecturas en microsegundos con DAX
DAX es una caché en memoria totalmente gestionada y compatible con DynamoDB que se pone delante de tu tabla. Devuelve lecturas eventualmente consistentes en microsegundos — hasta una mejora de 10x sobre los milisegundos — sin invalidación de caché que gestionar. No encaja con cargas que necesitan lecturas fuertemente consistentes.
El número que ven de verdad tus usuarios
Los milisegundos de un solo dígito se miden en el endpoint de DynamoDB. Lo que experimenta tu aplicación es eso más la red, y la red suele ser la mitad más grande por mucho.
Medido desde una máquina en España el 2026-07-28, nueve muestras por región, mediana del handshake TCP contra cada endpoint regional de DynamoDB. Eso es un viaje de ida y vuelta, antes de enviar un solo byte de petición:
| Región | Mediana del handshake TCP |
|---|---|
| eu-central-1 (Fráncfort) | 46,6 ms |
| eu-south-2 (España) | 49,1 ms |
| eu-west-1 (Irlanda) | 53,8 ms |
| us-east-1 (Virginia N.) | 113,6 ms |
| ap-northeast-1 (Tokio) | 259,5 ms |
Una máquina, un ISP, una tarde, así que léelos como órdenes de magnitud más que como un benchmark. Dos cosas en ellos valen en general. Un viaje transatlántico de ida y vuelta es más de diez veces la lectura que transporta, así que a esa distancia la latencia de DynamoDB es un error de redondeo dentro de la tuya. Y la región geográficamente más cercana a la máquina no fue la más rápida desde ella: eu-south-2 está en España y no midió mejor que Fráncfort, porque quien decide es el enrutamiento, no la distancia.
La versión práctica es que colocar el cómputo junto a la tabla gana a cualquier ajuste de DynamoDB que puedas hacer. Una función Lambda en la región de la tabla paga una fracción de los números de arriba; un portátil o un job de CI en otro continente los paga todos en cada conexión, que es también por lo que reutilizar la conexión del SDK importa más de lo que parece.
Qué puede frenarte
- Escaneos y filtros — leer la tabla entera es lento y caro; diseña en su lugar accesos basados en claves.
- Particiones calientes — cuando una clave de partición atrae mucho más tráfico del que le corresponde, las peticiones contra ella se limitan aunque la capacidad global de la tabla vaya sobrada.
Lo que mantiene rápido a DynamoDB es un buen diseño de claves, no más hardware.
Profundiza
Lee query vs scan y evita una partición caliente. Descarga DynoTable para ver qué lecturas se ejecutan como Query y cuáles como Scan.
Referencias
- Fast NoSQL Key-Value Database — Amazon DynamoDB — AWS
- In-memory acceleration with DynamoDB Accelerator (DAX) — Amazon DynamoDB Developer Guide
- What is Amazon DynamoDB? — Amazon DynamoDB Developer Guide
- Core components of Amazon DynamoDB — Amazon DynamoDB Developer Guide
Verificado por última vez el 2026-07-13 contra la documentación oficial de AWS enlazada arriba.
Cifras de latencia medidas el 2026-07-28 desde una única máquina en España con curl, nueve peticiones por región, reportando la mediana de time_connect menos time_namelookup contra https://dynamodb.<region>.amazonaws.com. Dos ejecuciones independientes coincidieron con un margen de 3 ms.