DynamoDB Capacity & Item Size Calculator

Check a DynamoDB item's size against the 400 KB limit

A DynamoDB item can be at most 400 KB, which is 409,600 bytes counted as the UTF-8 length of every attribute name plus the size of every value, nested maps and lists included. Paste a plain JSON item above to estimate its size, check the limit, and see which attributes use the space. Numbers are approximate because AWS does not publish an exact numeric encoding, and JavaScript cannot preserve every 38-digit DynamoDB number. The result is a size estimate, not a complete validation of keys or attribute types.

Paste plain JSON, not DynamoDB type wrappers such as S orN. JSON arrays are calculated as Lists, not sets. JSON has no binary type: a base64 string pasted here counts as a string, not decoded binary. For actual sets and binary attributes, apply the rules below. ReturnConsumedCapacity reports consumed units for real requests, not an exact item byte count.

Go over and PutItem or UpdateItem fails with ValidationException: Item size has exceeded the maximum allowed size. The limit cannot be increased. The usual ways around it are to compress the offending attribute, to move it to S3 and store its key in the item, or to split a wide item into an item collection under the same partition key. Item collections have their own cap, 10 GB, and only when the table has a local secondary index.

Long attribute names are the quiet cost. A name like customerShippingAddressLine1 spends 28 bytes on every item that carries it, and on every read and write of that item. Short names on hot, narrow items are worth the readability trade; the breakdown above shows when a name outweighs its value.

How DynamoDB sizes each attribute type

Attribute names always count, including names inside maps. Strings use their UTF-8 byte length: ASCII characters take one byte, while other characters can take multiple bytes. JSON punctuation and whitespace do not count toward the stored item.

• Numbers: AWS estimates about one byte per two significant digits, plus one byte; leading and trailing zeros are trimmed. Numeric storage is approximate, so leave margin near the item limit.
• Binary: count the decoded raw bytes, not the base64 representation sent over the network.
• Boolean and null: one byte per value, plus the attribute name.
• Lists and maps: three bytes per container, plus one byte per nested element, plus the nested names and values.
• String, number and binary sets: the attribute name plus each member's size, with no list or map overhead. A JSON array with two strings is a List and includes overhead that a string set does not.

For example, {"pk":"A","tags":["x","yz"],"active":true} is 22 bytes: 3 for pk, 12 for tags (4 bytes for the name, 3 for the container, 2 for element markers and 3 for values), and 7 for active. The three contributions are 3 + 12 + 7 = 22 bytes.

Storage billing adds at least 100 bytes per item, separately from the 400 KB limit and capacity calculations. Global tables add another 48 bytes, and some other features add system attributes. See the AWS item size rules.

How capacity is calculated from item size

DynamoDB bills reads and writes in capacity units, and the number you consume is driven by item size rounded up to a fixed boundary. Provisioned tables call them read and write capacity units, measured per second; on-demand tables call them read and write request units, billed per request. The arithmetic is identical either way.

Reads round up to the next 4 KB. A strongly consistent read of an item up to 4 KB costs one read unit, an eventually consistent read costs half a unit, and a transactional read costs two. So an 8 KB item costs 2 units strongly consistent, 1 eventually consistent, or 4 transactional.

Writes round up to the next 1 KB. A write of an item up to 1 KB costs one write unit, and a transactional write costs two.

Two things catch people out. Batch operations round each item individually before summing, so a BatchGetItem of a 1.5 KB and a 6.5 KB item costs 12 KB of reads, not 8 KB. And UpdateItem is billed on the larger of the item before and after the update, even when you only touch one attribute.

Query and Scan differ from BatchGetItem: they total the item bytes evaluated in each request before rounding to 4 KB. Filters and projection expressions do not reduce the bytes evaluated. Deleting an existing item uses its old size, while replacing an item with PutItem uses the larger old or new size.

Once you know the units, the DynamoDB pricing calculator turns them into a monthly cost.