DynamoDB Batch Write, Delete and Update: Code and Limits

Last updated: October 23rd, 2026

Updating many items at once? Dynobase applies attribute changes to selected items or matching results, shows the scope before writing, and keeps item history with undo. Bulk editing in Dynobase

DynamoDB BatchWriteItem sends up to 25 put or delete operations across one or more tables in a request of at most 16 MB. It does not support UpdateItem actions or conditions, and the batch is not atomic. A successful response can contain UnprocessedItems, which you must retry with backoff before declaring the batch complete.

Batch operations in DynamoDB

Batching reduces network requests and lets DynamoDB process independent items in parallel. It does not discount the capacity used by each item, guarantee a particular latency, or protect the group from partial completion.

Operation	What it groups	Limit	Atomic group?
`BatchWriteItem`	Puts and deletes	25 actions, 16 MB request	No
`BatchGetItem`	Reads by complete primary key	100 items, 16 MB response	No
PartiQL `BatchExecuteStatement`	Item-level statements, all reads or all writes	25 statements	No
`TransactWriteItems`	Puts, updates, deletes and condition checks	100 unique items, 4 MB aggregate item data	Yes

All stored items must fit the 400 KB item limit. The 16 MB write-request limit measures the serialized request; DynamoDB JSON and binary encodings can make the wire payload larger than the stored data. See the BatchWriteItem API reference.

DynamoDB batch write

What is a batch write?

A batch contains a RequestItems object mapping table names to arrays of PutRequest or DeleteRequest objects. The 25-action limit applies to the whole request, not separately to each table. You can mix puts and deletes, but cannot target the same item twice in one batch.

A PutRequest behaves like an unconditional PutItem: an existing item at that full key is replaced, and omitted attributes disappear. It is not a merge or partial update. For create-only writes or expected-version checks, use the conditional write APIs.

SDK v3: write a batch and retry unprocessed items

The sample tables dynobase-batch-operations and dynobase-batch-operations-2 both have string partition keys named id. The helper below processes one already-sized batch, uses jittered exponential backoff for partial results, and returns the remaining requests if its retry budget is exhausted.

import { setTimeout as sleep } from "node:timers/promises"
import { DynamoDBClient } from "@aws-sdk/client-dynamodb"
import { DynamoDBDocumentClient, BatchWriteCommand } from "@aws-sdk/lib-dynamodb"

const db = DynamoDBDocumentClient.from(new DynamoDBClient({ maxAttempts: 3 }))

async function writeBatch(requestItems, maxAttempts = 8) {
  let pending = requestItems
  for (let attempt = 0; attempt < maxAttempts; attempt += 1) {
    let result
    try {
      result = await db.send(new BatchWriteCommand({
        RequestItems: pending,
        ReturnConsumedCapacity: "TOTAL",
      }))
    } catch (error) {
      // Retain the unresolved request for a checkpoint or reconciliation.
      error.pendingRequestItems = pending
      throw error
    }
    pending = Object.fromEntries(
      Object.entries(result.UnprocessedItems ?? {}).filter(([, items]) => items.length > 0)
    )
    if (Object.keys(pending).length === 0) return pending
    if (attempt + 1 < maxAttempts) {
      const ceilingMs = Math.min(5000, 100 * 2 ** attempt)
      await sleep(Math.random() * ceilingMs)
    }
  }
  return pending
}

const remaining = await writeBatch({
  "dynobase-batch-operations": [
    { PutRequest: { Item: { id: "1", name: "Lakindu Hewawasam", age: 19, country: "Sri Lanka" } } },
    { PutRequest: { Item: { id: "2", name: "John Doe", age: 19, country: "USA" } } },
    { PutRequest: { Item: { id: "3", name: "Joe", age: 19, country: "Norway" } } },
  ],
})
if (Object.keys(remaining).length > 0) {
  throw Object.assign(new Error("Batch incomplete; checkpoint remaining requests"), {
    pendingRequestItems: remaining,
  })
}import { setTimeout as sleep } from "node:timers/promises"
import { DynamoDBClient } from "@aws-sdk/client-dynamodb"
import { DynamoDBDocumentClient, BatchWriteCommand } from "@aws-sdk/lib-dynamodb"

const db = DynamoDBDocumentClient.from(new DynamoDBClient({ maxAttempts: 3 }))

async function writeBatch(requestItems, maxAttempts = 8) {
  let pending = requestItems
  for (let attempt = 0; attempt < maxAttempts; attempt += 1) {
    let result
    try {
      result = await db.send(new BatchWriteCommand({
        RequestItems: pending,
        ReturnConsumedCapacity: "TOTAL",
      }))
    } catch (error) {
      // Retain the unresolved request for a checkpoint or reconciliation.
      error.pendingRequestItems = pending
      throw error
    }
    pending = Object.fromEntries(
      Object.entries(result.UnprocessedItems ?? {}).filter(([, items]) => items.length > 0)
    )
    if (Object.keys(pending).length === 0) return pending
    if (attempt + 1 < maxAttempts) {
      const ceilingMs = Math.min(5000, 100 * 2 ** attempt)
      await sleep(Math.random() * ceilingMs)
    }
  }
  return pending
}

const remaining = await writeBatch({
  "dynobase-batch-operations": [
    { PutRequest: { Item: { id: "1", name: "Lakindu Hewawasam", age: 19, country: "Sri Lanka" } } },
    { PutRequest: { Item: { id: "2", name: "John Doe", age: 19, country: "USA" } } },
    { PutRequest: { Item: { id: "3", name: "Joe", age: 19, country: "Norway" } } },
  ],
})
if (Object.keys(remaining).length > 0) {
  throw Object.assign(new Error("Batch incomplete; checkpoint remaining requests"), {
    pendingRequestItems: remaining,
  })
}

The retry counts and delays are example application settings, not DynamoDB limits. The SDK retries eligible request-level exceptions according to its configuration; it does not automatically resubmit a successful response's UnprocessedItems. That is the helper's job.

If a request ends with a network error, some outcomes can be uncertain. Persist the unresolved work and reconcile when concurrent writers matter. Replaying an unconditional put can overwrite a newer edit; replaying a delete can remove a newly recreated item at the same key.

Writing to multiple tables

Using the same helper, add another table entry. Four actions below still count as one four-action batch:

const remaining = await writeBatch({
  "dynobase-batch-operations": [
    { PutRequest: { Item: { id: "6", name: "Lakindu Hewawasam" } } },
    { PutRequest: { Item: { id: "7", name: "John Doe" } } },
  ],
  "dynobase-batch-operations-2": [
    { PutRequest: { Item: { id: "1", name: "Mark" } } },
    { PutRequest: { Item: { id: "2", name: "Joseph" } } },
  ],
})
if (Object.keys(remaining).length > 0) {
  throw Object.assign(new Error("Multi-table batch incomplete"), { pendingRequestItems: remaining })
}const remaining = await writeBatch({
  "dynobase-batch-operations": [
    { PutRequest: { Item: { id: "6", name: "Lakindu Hewawasam" } } },
    { PutRequest: { Item: { id: "7", name: "John Doe" } } },
  ],
  "dynobase-batch-operations-2": [
    { PutRequest: { Item: { id: "1", name: "Mark" } } },
    { PutRequest: { Item: { id: "2", name: "Joseph" } } },
  ],
})
if (Object.keys(remaining).length > 0) {
  throw Object.assign(new Error("Multi-table batch incomplete"), { pendingRequestItems: remaining })
}

For a larger dataset, build batches with at most 25 actions and check their serialized size. A simple count-only chunker is insufficient for large binary attributes. Checkpoint completed batches and retain each pending subset rather than restart the entire import.

boto3 batch writer

The boto3 batch writer buffers requests, sends batches and resends unprocessed items. Use it as a context manager so the final buffered items are flushed on exit.

import boto3

table = boto3.resource("dynamodb").Table("dynobase-batch-operations")
rows = [
    {"id": "1", "name": "Lakindu Hewawasam", "age": 19},
    {"id": "2", "name": "John Doe", "age": 19},
    {"id": "3", "name": "Joe", "age": 19},
]

with table.batch_writer() as batch:
    for item in rows:
        batch.put_item(Item=item)import boto3

table = boto3.resource("dynamodb").Table("dynobase-batch-operations")
rows = [
    {"id": "1", "name": "Lakindu Hewawasam", "age": 19},
    {"id": "2", "name": "John Doe", "age": 19},
    {"id": "3", "name": "Joe", "age": 19},
]

with table.batch_writer() as batch:
    for item in rows:
        batch.put_item(Item=item)

The context manager is for one table. Use a separate writer for another table or the low-level batch_write_item client for an explicit multi-table request. The helper handles buffering and partial retries, but your job still needs failure reporting, checkpoints and an operational deadline.

overwrite_by_pkeys=["id"] deduplicates matching keys in the helper's local buffer. It does not add a create-only condition or prevent overwriting existing table data. Use it only when last-in-buffer behavior is intended.

DynamoDB batch delete

What is a batch delete?

There is no separate BatchDeleteItem API. Submit DeleteRequest entries to BatchWriteItem, with the complete key of every item. If the table has a sort key, it is required too.

The same JavaScript helper handles a multi-table delete:

const remaining = await writeBatch({
  "dynobase-batch-operations": [
    { DeleteRequest: { Key: { id: "1" } } },
    { DeleteRequest: { Key: { id: "2" } } },
  ],
  "dynobase-batch-operations-2": [
    { DeleteRequest: { Key: { id: "10" } } },
    { DeleteRequest: { Key: { id: "22" } } },
  ],
})
if (Object.keys(remaining).length > 0) {
  throw Object.assign(new Error("Delete batch incomplete"), { pendingRequestItems: remaining })
}const remaining = await writeBatch({
  "dynobase-batch-operations": [
    { DeleteRequest: { Key: { id: "1" } } },
    { DeleteRequest: { Key: { id: "2" } } },
  ],
  "dynobase-batch-operations-2": [
    { DeleteRequest: { Key: { id: "10" } } },
    { DeleteRequest: { Key: { id: "22" } } },
  ],
})
if (Object.keys(remaining).length > 0) {
  throw Object.assign(new Error("Delete batch incomplete"), { pendingRequestItems: remaining })
}

With boto3:

import boto3

table = boto3.resource("dynamodb").Table("dynobase-batch-operations")
with table.batch_writer() as batch:
    for item_id in ["1", "2"]:
        batch.delete_item(Key={"id": item_id})import boto3

table = boto3.resource("dynamodb").Table("dynobase-batch-operations")
with table.batch_writer() as batch:
    for item_id in ["1", "2"]:
        batch.delete_item(Key={"id": item_id})

A batch delete cannot check a version, return the deleted item or delete by filter expression. Fetch candidate keys first when necessary, then delete them. If deleting only the exact revision you inspected matters, use conditional DeleteItem instead. A delete of a nonexistent item still consumes write capacity.

DynamoDB batch get

What is a batch get?

BatchGetItem fetches known keys, including keys from several tables. It does not run multiple queries or search by arbitrary attributes. Reads are eventually consistent by default; set ConsistentRead inside each table entry when needed.

This SDK v3 example preserves results while retrying UnprocessedKeys. Both tables use the same simple id schema as above.

import { setTimeout as sleep } from "node:timers/promises"
import { DynamoDBClient } from "@aws-sdk/client-dynamodb"
import { DynamoDBDocumentClient, BatchGetCommand } from "@aws-sdk/lib-dynamodb"

const db = DynamoDBDocumentClient.from(new DynamoDBClient({}))
let pending = {
  "dynobase-batch-operations": { Keys: [{ id: "1" }, { id: "2" }] },
  "dynobase-batch-operations-2": { Keys: [{ id: "1" }, { id: "2" }], ConsistentRead: true },
}
const itemsByTable = {}

for (let attempt = 0; attempt < 8; attempt += 1) {
  const result = await db.send(new BatchGetCommand({ RequestItems: pending }))
  for (const [table, items] of Object.entries(result.Responses ?? {})) {
    itemsByTable[table] = [...(itemsByTable[table] ?? []), ...items]
  }
  pending = result.UnprocessedKeys ?? {}
  if (Object.keys(pending).length === 0) break
  if (attempt < 7) await sleep(Math.random() * Math.min(5000, 100 * 2 ** attempt))
}
if (Object.keys(pending).length > 0) {
  throw Object.assign(new Error("Read batch incomplete"), { pending, itemsByTable })
}
console.log(itemsByTable)import { setTimeout as sleep } from "node:timers/promises"
import { DynamoDBClient } from "@aws-sdk/client-dynamodb"
import { DynamoDBDocumentClient, BatchGetCommand } from "@aws-sdk/lib-dynamodb"

const db = DynamoDBDocumentClient.from(new DynamoDBClient({}))
let pending = {
  "dynobase-batch-operations": { Keys: [{ id: "1" }, { id: "2" }] },
  "dynobase-batch-operations-2": { Keys: [{ id: "1" }, { id: "2" }], ConsistentRead: true },
}
const itemsByTable = {}

for (let attempt = 0; attempt < 8; attempt += 1) {
  const result = await db.send(new BatchGetCommand({ RequestItems: pending }))
  for (const [table, items] of Object.entries(result.Responses ?? {})) {
    itemsByTable[table] = [...(itemsByTable[table] ?? []), ...items]
  }
  pending = result.UnprocessedKeys ?? {}
  if (Object.keys(pending).length === 0) break
  if (attempt < 7) await sleep(Math.random() * Math.min(5000, 100 * 2 ** attempt))
}
if (Object.keys(pending).length > 0) {
  throw Object.assign(new Error("Read batch incomplete"), { pending, itemsByTable })
}
console.log(itemsByTable)

Batch get limits and best practices

The response is limited to 100 items and 16 MB, and partial results can also occur because of per-partition response limits or throttling. If nothing can be processed, the API can raise a throughput exception. Missing items are omitted; results are unordered, so retain key attributes when projecting fields.

Use ProjectionExpression rather than legacy AttributesToGet. A smaller projection reduces response payload but not the underlying read capacity for the item. Strong reads cost twice the capacity of eventual reads, and a strong batch still is not a multi-item snapshot. Details are in the read consistency guide.

DynamoDB batch update

Why BatchWriteItem cannot update attributes

Its request model contains only puts and deletes. Reading a whole item, modifying one field and batch-putting it back can erase another writer's intervening change. Use UpdateItem when you intend to preserve unspecified attributes.

There are three alternatives:

Parallel UpdateItem requests for independent changes, each with its own condition and outcome.
PartiQL BatchExecuteStatement for up to 25 independent write statements, including updates and conditions. Inspect each statement's Error even if the HTTP request succeeds.
TransactWriteItems when related updates must commit together. Its atomicity costs additional capacity and can increase contention.

The PartiQL batch API reference explains the separate statement results. PartiQL does not turn an arbitrary multi-row update into one statement: each update identifies one item.

Paginated bulk update with bounded concurrency

For the existing example, set visibility to private on items whose id starts with user. Partition-key prefixes cannot be queried directly, so this example scans. If your schema has a queryable grouping key, use that access pattern instead.

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

const db = DynamoDBDocumentClient.from(new DynamoDBClient({}))
const TableName = "dynobase-batch-operations"
let cursor

do {
  const page = await db.send(new ScanCommand({
    TableName,
    ExclusiveStartKey: cursor,
    ProjectionExpression: "#id",
    FilterExpression: "begins_with(#id, :prefix)",
    ExpressionAttributeNames: { "#id": "id" },
    ExpressionAttributeValues: { ":prefix": "user" },
  }))
  const items = page.Items ?? []
  for (let start = 0; start < items.length; start += 8) {
    const group = items.slice(start, start + 8)
    const outcomes = await Promise.allSettled(group.map(item => db.send(new UpdateCommand({
      TableName,
      Key: { id: item.id },
      UpdateExpression: "SET #visibility = :private",
      ConditionExpression: "attribute_exists(#id)",
      ExpressionAttributeNames: { "#visibility": "visibility", "#id": "id" },
      ExpressionAttributeValues: { ":private": "private" },
    }))))
    const failed = outcomes.flatMap((outcome, index) =>
      outcome.status === "rejected" ? [{ key: group[index], error: outcome.reason }] : []
    )
    if (failed.length > 0) {
      throw Object.assign(new Error("Update group incomplete"), { failed, pageStartKey: cursor })
    }
  }
  cursor = page.LastEvaluatedKey
} while (cursor)import { DynamoDBClient } from "@aws-sdk/client-dynamodb"
import { DynamoDBDocumentClient, ScanCommand, UpdateCommand } from "@aws-sdk/lib-dynamodb"

const db = DynamoDBDocumentClient.from(new DynamoDBClient({}))
const TableName = "dynobase-batch-operations"
let cursor

do {
  const page = await db.send(new ScanCommand({
    TableName,
    ExclusiveStartKey: cursor,
    ProjectionExpression: "#id",
    FilterExpression: "begins_with(#id, :prefix)",
    ExpressionAttributeNames: { "#id": "id" },
    ExpressionAttributeValues: { ":prefix": "user" },
  }))
  const items = page.Items ?? []
  for (let start = 0; start < items.length; start += 8) {
    const group = items.slice(start, start + 8)
    const outcomes = await Promise.allSettled(group.map(item => db.send(new UpdateCommand({
      TableName,
      Key: { id: item.id },
      UpdateExpression: "SET #visibility = :private",
      ConditionExpression: "attribute_exists(#id)",
      ExpressionAttributeNames: { "#visibility": "visibility", "#id": "id" },
      ExpressionAttributeValues: { ":private": "private" },
    }))))
    const failed = outcomes.flatMap((outcome, index) =>
      outcome.status === "rejected" ? [{ key: group[index], error: outcome.reason }] : []
    )
    if (failed.length > 0) {
      throw Object.assign(new Error("Update group incomplete"), { failed, pageStartKey: cursor })
    }
  }
  cursor = page.LastEvaluatedKey
} while (cursor)

The group size of eight is an example concurrency bound. The loop continues even when a filtered page is empty, because LastEvaluatedKey is the pagination signal. The existence condition avoids recreating an item deleted since the scan. Add expected versions if this migration must not overwrite concurrent visibility edits.

Setting a field to a fixed value makes a simple restart easier than repeating an increment, but it still has application semantics. Save failures and page checkpoints in a durable job record before considering a migration resumable. Promise.allSettled lets the job account for every request in the current group before reporting failure.

Capacity, performance and failure planning

Batches still consume the capacity of their individual operations. Each write is rounded by item size, and changed indexes add their own work. A small number of hot partition keys can throttle a job even when total table capacity looks sufficient. Table throughput quotas and configured on-demand maximums are separate from the fixed 25-action batch limit.

A physical partition supports up to 1,000 write units per second, not 1,000 writes of any size. Spread independent work across keys, observe consumed capacity and throttle reasons, and reduce concurrency when retries dominate. Avoid claiming a fixed table-wide write ceiling: quotas, configured limits and capacity mode all matter.

Prefer queries to broad scans where the data model permits them. A GSI can help locate candidate keys, but its eventual consistency and added write costs should be part of the design. For large migrations, validate counts, retain a failure manifest and verify the intended final state; an HTTP success alone is not completion.

Frequently Asked Questions

How many items can DynamoDB BatchWriteItem write?

Up to 25 put or delete actions across all tables in one request, with a maximum request size of 16 MB. Each stored item must fit 400 KB.

Can BatchWriteItem update an item?

It can replace an item through PutRequest, but cannot perform a partial UpdateItem operation. Use individual updates, PartiQL batches or transactions for attribute changes.

Does boto3 batch_writer retry unprocessed items?

Yes. It buffers requests and resends unprocessed items as needed. Your application still needs to handle exceptions, job deadlines and durable progress reporting.

Are batch writes atomic?

Each put or delete is atomic, but the group is not. Some actions can succeed while others are returned in UnprocessedItems. Transactions provide all-or-nothing grouping.

How many writes can DynamoDB handle?

Throughput depends on item size, key distribution, capacity mode and configured quotas. A physical partition supports up to 1,000 write units per second; batching does not bypass that capacity limit.

Dynobase is a Professional GUI Client for DynamoDB

Start your 7-day free trial today

Product Features

DynamoDB Tools

DynamoDB Info

DynamoDB Guides