¿Se puede ejecutar DynamoDB en local?

Sí. AWS distribuye DynamoDB Local, una versión descargable y gratuita de DynamoDB que se ejecuta en tu propia máquina como imagen de Docker, ejecutable de Java o dependencia de Apache Maven. Expone la misma API que el servicio web, así que puedes desarrollar y probar sin conexión y luego, sin más, apuntar tu código a AWS.

Tres formas de ejecutarlo

Imagen de Docker — la opción más habitual: un docker run y el endpoint está levantado en un puerto local.
Archivo descargable — una aplicación Java que lanzas directamente (requiere un JRE).
Dependencia de Apache Maven — para empotrarlo en las suites de pruebas de la JVM.

Por qué desarrollar en local

La base de datos es autocontenida en tu ordenador, así que te ahorras las tarifas de rendimiento, almacenamiento de datos y transferencia de datos — y no necesitas conexión a internet mientras desarrollas. Cuando estés listo para desplegar, quitas el endpoint local del código y este apunta al servicio web de DynamoDB.

Ojo con las diferencias

DynamoDB Local emula la API, pero no es el motor de producción — AWS documenta diferencias de comportamiento en sus notas de uso (el rendimiento no se aplica, por ejemplo). Trátalo como un doble funcional de desarrollo y pruebas, no como un modelo de rendimiento.

Tres divergencias que hemos medido

Mantenemos un contenedor de DynamoDB Local en marcha para reproducir los errores que citamos en nuestras páginas de errores, lo que significa que chocamos con sus bordes con regularidad. Tres merecen conocerse antes de fiarte de una prueba local en verde.

El rendimiento aprovisionado no se aplica en absoluto. Creamos una tabla a 1 RCU, escribimos un Item de 3,5 KB y lo leímos de vuelta con consistencia fuerte en un bucle con los reintentos del SDK desactivados (maxAttempts: 1):

reads=5000 ok=5000 errors=0 elapsed=2.5s rate=1997/s

Cinco mil lecturas, cero limitaciones, unas 2.000 unidades de lectura por segundo sostenidas contra una tabla aprovisionada para una. El mismo bucle contra el servicio en vivo lanza ProvisionedThroughputExceededException en la lectura 49. Un bug de capacidad no puede fallar en local.

Un error cambia de nombre. Ejecuta el mismo INSERT de PartiQL dos veces y DynamoDB Local responde DuplicateItem con el mensaje Duplicate primary key exists in table. El servicio responde DuplicateItemException con There was an attempt to insert an item with the same primary key as an item that already exists in the DynamoDB table. Un manejo de errores que bifurque por el nombre pasa en local y falla en producción.

Algunas API simplemente no están. ExportTableToPointInTime responde:

UnknownOperationException: An unknown operation was requested.

Ese no es el error del servicio para esa misma llamada, así que una ruta de código que se proteja frente a PointInTimeRecoveryUnavailableException tampoco se puede ejercitar en local.

Profundiza

La guía de DynamoDB Local recorre la configuración paso a paso, y la guía de conexión local y LocalStack muestra cómo apuntarle una GUI — DynoTable se conecta a endpoints locales exactamente igual que se conecta a AWS. Prueba tu primera consulta con el generador de expresiones.

Referencias

Verificado por última vez el 2026-07-13 contra la documentación oficial de AWS enlazada arriba.

Las tres divergencias se reprodujeron el 2026-07-28 contra DynamoDB Local 3.3.0 (amazon/dynamodb-local, Corretto 17.0.17) con @aws-sdk/client-dynamodb 3.1095.0 en Node v24.18.0. Cada línea de salida de arriba es del propio motor, sin editar.