Cómo borrar varios items en DynamoDB
No hay DELETE FROM table WHERE … en DynamoDB. Cada delete apunta a un
item por su clave primaria completa — la API no tiene operación de borrado masivo, no
tiene truncate, y el DELETE de quita exactamente un item por
statement. Así que "borrar varios items" es siempre un trabajo de dos pasos: encontrar las
claves, luego emitir un delete por clave, en lote para el throughput.
Esta guía cubre las opciones de batching, la variante transaccional todo-o-nada, el caso de borrar-todo, y cómo hacer lo mismo con una selección y dos teclas en una GUI.
¿Cómo borro varios items en DynamoDB?
Recoge las claves primarias de los items que quieres quitar (vía Query o Scan),
luego bórralos en lotes: BatchWriteItem admite hasta 25
DeleteRequests por llamada, TransactWriteItems borra hasta 100 items de forma
atómica, y los statements PartiQL DELETE se pueden agrupar de 25 en 25 con
BatchExecuteStatement. En DynoTable seleccionas las filas y
pulsas ⌘⌫ para stagear
los deletes, luego revisas y confirmas.
- Masivo, best-effort:
BatchWriteItem— 25 deletes por llamada, reintenta lo que queda. - Todo-o-nada:
TransactWriteItems— hasta 100 acciones que tienen éxito o fallan juntas. - Sintaxis con sabor SQL: PartiQL
DELETE+BatchExecuteStatement— la misma regla por clave, ortografía familiar. - Todo en la tabla: estrategias de truncate — normalmente es más barato dropear y recrear la tabla.
- Una selección visual: deletes stageados en DynoTable — selecciona filas, stagea, revisa los diffs rojos, confirma.
Paso 0: recoge las claves
Un delete necesita la clave primaria entera — en una tabla eso es
la clave de partición y la clave de ordenación
(AWS:
"For each primary key, you must provide all of the key attributes"). No
puedes borrar por un atributo arbitrario, así que "borrar cada item donde
status = 'archived'" empieza con una lectura:
- Si la condición vive en una clave (o una clave de GSI), un
Querydirigido recoge las claves barato. - Si no, es un
Scancon filtro — que lee (y factura) toda la tabla, con o sin filtro; mira query vs scan.
Usa una ProjectionExpression que solo devuelva los atributos de clave, y sigue
LastEvaluatedKey hasta el final (paginación) o borrarás
en silencio solo la primera página de 1 MB.
Método 1: BatchWriteItem (hasta 25 deletes por llamada)
BatchWriteItem empaqueta hasta 25 put/delete requests o 16 MB por llamada
(referencia de la API AWS:
"Una sola llamada a BatchWriteItem puede transmitir hasta 16 MB de datos por la
red, formados por hasta 25 operaciones de escritura o eliminación de elementos").
aws dynamodb batch-write-item --request-items '{
"Orders": [
{"DeleteRequest": {"Key": {"PK": {"S": "ORDER#1001"}, "SK": {"S": "META"}}}},
{"DeleteRequest": {"Key": {"PK": {"S": "ORDER#1002"}, "SK": {"S": "META"}}}},
{"DeleteRequest": {"Key": {"PK": {"S": "ORDER#1003"}, "SK": {"S": "META"}}}}
]
}'Tres propiedades del lote tropiezan a la gente — todas sacadas de la referencia de la API:
- No es atómico: "Las operaciones individuales
PutItemyDeleteItemespecificadas enBatchWriteItemson atómicas; sin embargo,BatchWriteItemen su conjunto no lo es." Algunos deletes pueden aterrizar mientras otros no. - Debes reintentar
UnprocessedItems. Las peticiones con throttle vuelven en el mapa de respuestaUnprocessedItems, con la misma forma que la petición — "Typically, you would callBatchWriteItemin a loop", y AWS "strongly recommend[s] that you use an exponential backoff algorithm" entre reintentos. - Sin condiciones. "You cannot specify conditions on individual put and
delete requests" — un delete condicional tiene que ir por
DeleteItemo una transacción. Un lote también rechaza dos operaciones sobre la misma clave en una llamada.
La forma del loop — trocea de 25, envía, reencola lo que queda con backoff — es la misma cubierta en operaciones por lotes.
Método 2: TransactWriteItems (deletes atómicos)
Cuando un conjunto de deletes debe tener éxito o fallar juntos — quitar un item
padre y los hijos de su , por ejemplo — usa TransactWriteItems: hasta
100 acciones (deletes, puts, updates, condition checks) aplicadas de forma atómica,
con por item permitidas. El trade: una escritura
transaccional cuesta el doble de write capacity de una
escritura simple. La mecánica completa (idempotency tokens,
TransactionCanceledException, cálculo de coste) está en
transacciones DynamoDB.
Método 3: PartiQL DELETE, en lote
PartiQL no levanta la regla "una clave a la vez" — solo la reescribe de otra forma.
El developer guide es explícito
(PartiQL DELETE):
"You can delete only one item at a time. You cannot issue a single DynamoDB
PartiQL statement that deletes multiple items", y la condición WHERE
"must resolve to a single primary key value".
Para borrar varios items, agrupas statements de un solo item —
BatchExecuteStatement
ejecuta hasta 25 statements por lote (todos de lectura o todos de
escritura, nunca mezclados):
[
{"Statement": "DELETE FROM \"Orders\" WHERE PK = 'ORDER#1001' AND SK = 'META'"},
{"Statement": "DELETE FROM \"Orders\" WHERE PK = 'ORDER#1002' AND SK = 'META'"}
]aws dynamodb batch-execute-statement --statements file://statements.jsonUn WHERE que no fija la clave completa falla — no hay
DELETE FROM Orders WHERE status = 'archived'. Más patrones PartiQL (y los
límites detrás) en ejemplos PartiQL y
PartiQL vs SQL.
Borrar TODOS los items (truncate)
DynamoDB no tiene truncate. Tus opciones, por orden de preferencia:
- Borrar y recrear la tabla. El delete item a item de una tabla
entera factura una escritura por item;
DeleteTable+CreateTableevita toda la factura de escritura. El pie: los settings de tabla — índices, TTL, , capacity mode, tags — no vuelven solos; los redesclaras al crear (la infrastructure-as-code lo convierte en un no-evento). - Caducar items con . Si "borrar todo lo más viejo que X" es de verdad lo que quieres, el TTL borra los items caducados en background sin consumir write capacity — un borrado masivo a cámara lenta que no cuesta.
- Scan + delete por lotes (Método 1) cuando la tabla debe seguir en servicio y solo se va un subset — pagas una lectura por item escaneado más una escritura por item borrado.
Borrar varios items en DynoTable
El flujo seleccionar-luego-borrar de arriba — query, recoger claves, trocear, reintentar — es exactamente la faena que una GUI debería llevarse. En DynoTable, es una selección en la grid:
- Ejecuta o filtra una query para que las filas a borrar estén en pantalla.
- Selecciónalas y pulsa ⌘⌫ — cada fila seleccionada se convierte en un delete stageado. Nada ha tocado DynamoDB aún: las filas se tiñen de rojo en la grid y aparecen como tarjetas revisables en el panel de staging.
- Revisa, luego confirma. Los commits salen como lotes
TransactWriteItemscon condiciones de optimistic locking — un delete stageado solo pasa si el item sigue existiendo — y los lotes grandes se trocean automáticamente para quedarse dentro de los límites de transacción de DynamoDB. ⌘⇧⌫ se salta la review y borra-y-confirma la selección en un solo atajo.

El alcance es honesto: borras las filas que seleccionaste — una operación revisada, recuperable hasta el commit — no un truncate ciego de toda la tabla. Para vaciar una tabla entera, bórrala y recréala (arriba).
Si un delete necesita una condición escrita a mano
(attribute_exists, un check de versión), construye la
ConditionExpression exacta + los mapas de placeholders en el
DynamoDB Expression Builder y engánchala a
un DeleteItem o a una transacción.
FAQ
¿Puedo borrar varios items en una sola llamada DynamoDB?
Sí — hasta 25 con BatchWriteItem (best-effort, reintenta los
UnprocessedItems) o hasta 100 de forma atómica con TransactWriteItems.
Ambos exigen una clave primaria completa por item; ninguno acepta una condición
"where" para seleccionar los items.
¿Hay un DELETE WHERE en DynamoDB?
No. Ni la API de bajo nivel ni PartiQL pueden borrar por condición — el
DELETE de PartiQL exige un WHERE que "se resuelva a un solo valor de clave
primaria". Primero haces query o scan por las claves, luego borras cada una.
¿Cómo borro todos los items de una tabla DynamoDB? Para una limpieza completa, borra y recrea la tabla — evita pagar una escritura por item. Para una limpieza por edad, usa TTL, que borra items caducados sin consumir write capacity. Scan + delete por lotes es el plan B cuando la tabla debe seguir en servicio.
¿Por qué reaparecen items tras mi delete por lotes?
Casi siempre UnprocessedItems no reintentados: un BatchWriteItem
con throttle devuelve en silencio los deletes fallidos en la respuesta, y un
código que no loopea sobre ellos "termina" con items todavía en la tabla.
Reintenta con exponential backoff hasta que el mapa vuelva vacío.
¿Cuánto cuesta borrar items? Cada delete es una escritura estándar (una WCU por tramo de 1 KB, duplicada en una transacción), y encontrar las claves también cuesta lecturas. Estima el daño con la calculadora de pricing.
¿Prefieres ver lo que borras primero? Descarga DynoTable — selecciona las filas, stagea los deletes con ⌘⌫, revisa los diffs y confirma cuando estés seguro.


