¿DynamoDB cumple con ACID?

Sí. DynamoDB admite transacciones ACID mediante las API TransactWriteItems y TransactGetItems. Estas agrupan hasta 100 acciones en una única operación de todo o nada con garantías de atomicidad, consistencia, aislamiento y durabilidad dentro de una región de AWS. Las escrituras de un solo elemento también son atómicas y duraderas, pero el ACID sobre varios elementos requiere las API de transacción.

Qué significa aquí ACID

Una transacción de DynamoDB aplica todas las acciones o ninguna (atomicidad), deja los datos en un estado válido (consistencia), está aislada de las transacciones concurrentes y queda confirmada de forma duradera en cuanto devuelve éxito. Estas garantías se cumplen dentro de la región de AWS donde se invocó la API de transacción.

Las API de transacción

TransactWriteItems — una escritura síncrona e idempotente que agrupa acciones Put, Update, Delete y ConditionCheck.
TransactGetItems — una lectura atómica y consistente de varios elementos.

No puedes apuntar dos veces al mismo elemento en una transacción.

El límite es 100, no 25

La API Reference dice que TransactWriteItems "groups up to 100 action requests" y que "the aggregate size of the items in the transaction cannot exceed 4 MB" (consultada el 2026-07-28). La cifra era 25 antes de 2022, y el número obsoleto se sigue repitiendo lo bastante como para que merezca la pena comprobarlo contra la API y no contra una entrada de blog.

Una transacción de 100 acciones se acepta. Una de 101 se rechaza:

ValidationException: Member must have length less than or equal to 100

Fíjate en lo que ese mensaje no contiene: la palabra «transaction». Es una queja genérica sobre la longitud de un array, así que no aparecerá en una búsqueda de logs de errores de transacción. Las API de lotes son menos discretas al respecto. BatchGetItem con 101 claves devuelve Too many items requested for the BatchGetItem call, y BatchWriteItem con 26 devuelve la misma frase con su propio nombre dentro.

Apuntar dos veces al mismo elemento también falla, aunque cada acción tuviera éxito por separado:

ValidationException: Transaction request cannot include multiple operations on one item

Ese es el que pilla al código que construye la lista de acciones con un bucle sobre eventos entrantes sin deduplicar antes por clave.

Las transacciones además facturan el doble. Escribir 100 elementos de 1 KB de forma transaccional consume 200 unidades de escritura frente a 100 por los mismos elementos escritos individualmente, así que la atomicidad tiene un precio incluso cuando no falla nada.

¿Y las tablas globales?

Una transacción es ACID solo en la región donde se invocó. En tablas globales que usan el modo por defecto de consistencia eventual multirregión (MREC), las escrituras transaccionales no se replican como una unidad — otra región puede observar brevemente una transacción replicada a medias mientras se propagan los cambios. Las tablas globales configuradas con consistencia fuerte multirregión (MRSC) no admiten las API de transacción en absoluto.

Profundiza

Aprende a modelarlas con seguridad en transacciones en DynamoDB, y construye las expresiones de condición que necesitan con el Expression Builder. Pruébalo contra tus propias tablas — descarga DynoTable.

Referencias

Verificado por última vez el 2026-07-13 contra la documentación oficial de AWS enlazada arriba; los límites de 100 acciones y 4 MB se volvieron a consultar en la API Reference el 2026-07-28.

Los rechazos de arriba se reprodujeron el 2026-07-28 contra DynamoDB Local 3.3.0 (amazon/dynamodb-local:latest) mediante @aws-sdk/client-dynamodb 3.1095.0. Cada cadena citada es salida literal del motor.