DynamoDB’s BatchWriteItem and BatchGetItem operations let you perform multiple item operations in a single request, but they’re not unlimited. The real surprise is just how much throughput you can squeeze out of them if you understand their underlying mechanics.
Let’s see BatchWriteItem in action. Imagine you have a bunch of user profile updates to push. Instead of sending hundreds of individual PutItem requests, you can bundle them.
{
"RequestItems": {
"UserProfiles": [
{
"PutRequest": {
"Item": {
"UserId": {"S": "user123"},
"ProfileData": {"S": "some data"}
}
}
},
{
"PutRequest": {
"Item": {
"UserId": {"S": "user456"},
"ProfileData": {"S": "more data"}
}
}
}
// ... up to 25 items
]
}
}
This single JSON payload, sent via the AWS SDK or CLI, can contain up to 25 PutRequest or DeleteRequest operations. Similarly, BatchGetItem can fetch up to 100 items across one or more tables in a single call.
The problem these operations solve is efficiency. Each individual API call to DynamoDB incurs network latency and processing overhead. By batching, you dramatically reduce the number of round trips. For BatchWriteItem, the key limit is 25 operations per request. For BatchGetItem, it’s 100 items. But that’s not the whole story. The total size of all items in a BatchWriteItem request cannot exceed 1MB. For BatchGetItem, each individual item fetched cannot exceed 400KB.
The real power comes when you combine these batch operations with DynamoDB’s provisioned throughput. A single BatchWriteItem request consumes write capacity units (WCUs) based on the total number of items written and the size of each item. A BatchGetItem request consumes read capacity units (RCUs) based on the total number of items retrieved and their size. The critical insight is that a single batch request can consume multiple WCUs or RCUs concurrently, effectively allowing you to burst beyond the capacity of a single item operation.
Consider a scenario where you have a table with 100 WCUs provisioned. If you send 25 individual PutItem requests, each consuming 1 WCU, you’ll hit throttling if you try to send them too quickly. However, if you bundle those 25 items into a single BatchWriteItem request, and DynamoDB has the capacity, that single request can utilize up to 25 WCUs in parallel if the underlying hardware can support it. This is where the throughput advantage lies.
The common pitfall is assuming that a batch operation only consumes capacity as if it were a single item. It’s more nuanced. For BatchWriteItem, each PutRequest or DeleteRequest within the batch consumes 0.5 WCU for the operation itself, plus additional WCUs based on the item’s size (1 WCU per 1KB of item size, rounded up). So, a BatchWriteItem request with 25 items, each 1KB, would consume 25 * (0.5 + 1) = 37.5 WCUs if there were enough capacity. If you only had 10 WCUs provisioned, this single batch request would likely be throttled.
When BatchWriteItem or BatchGetItem requests are throttled, DynamoDB returns a UnprocessedItems field in the response. This is not an error; it’s an indication that some items in your batch could not be processed due to exceeding provisioned throughput. The correct way to handle this is to resend the UnprocessedItems in subsequent requests. A common pattern is to use exponential backoff for these retries.
The most powerful optimization, often overlooked, is understanding that BatchWriteItem can perform both PutRequest and DeleteRequest operations within the same request, up to the 25-item limit. This allows for complex atomic-like updates where you might delete old versions of an item and put new ones in a single, efficient call.
The next logical step after mastering batch operations is understanding how to distribute load across multiple DynamoDB tables or partitions to further maximize throughput.