Error: DynamoDB delete fails

A failed DynamoDB delete usually means the request used an invalid key, failed a condition, lacked permission, or was throttled. DeleteItem without a condition succeeds even when the item is already absent. Read the exception before changing the request.

Match the error to the fix

• ValidationException: supply exactly the base table’s key attributes, with the right names and types. A composite primary key requires both partition and sort key values.
• ConditionalCheckFailedException: compare the current item with the condition. A mapper’s version check can create this condition. A version attribute by itself does not make DynamoDB enforce optimistic locking.
• AccessDeniedException: grant the required delete action on the specific table and inspect explicit denies.
• ResourceNotFoundException: verify the table, Region, account, and endpoint.
• Throttling or a transaction conflict: use bounded retries with backoff and inspect the throttling reason. Increasing table capacity helps only when that capacity is the bottleneck.

A delete with an explicit condition

import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { DynamoDBDocumentClient, DeleteCommand } from "@aws-sdk/lib-dynamodb";

const db = DynamoDBDocumentClient.from(new DynamoDBClient({ region: "us-east-1" }));
const result = await db.send(new DeleteCommand({
  TableName: "Orders",
  Key: { pk: "ORDER#123", sk: "DETAIL" },
  ConditionExpression: "#status = :status",
  ExpressionAttributeNames: { "#status": "status" },
  ExpressionAttributeValues: { ":status": "CANCELLED" },
  ReturnValues: "ALL_OLD"
}));
console.log(result.Attributes);

This example deliberately refuses to delete an item whose current status is not CANCELLED, including an absent item. Handle that as a business decision rather than blindly retrying or removing the condition.

Backups and enabled Streams do not block ordinary deletes. An UPDATING table can still serve data operations; diagnose the actual response instead of assuming all updates require downtime. Awaiting an asynchronous SDK call is necessary to observe success or failure, but it does not bypass server-side validation.

See delete examples and AWS documentation.