DynamoDB Limits: Item Size, API Limits and Quotas

DynamoDB's maximum item size is 400 KB, including attribute names and values. Query and Scan evaluate at most 1 MB per page, batch writes accept 25 operations, and transactions cover at most 100 distinct items and 4 MB. These fixed constraints are separate from adjustable defaults such as 20 GSIs per table and 40,000 read or write units per second per table or GSI.

The tables below cover items, keys, indexes, operations, throughput, control-plane requests, Streams, backups and vector search. Values are checked against the AWS service quotas and constraints documentation. DynamoDB uses binary size units: 1 KB is 1,024 bytes, so 400 KB is 409,600 bytes.

Fixed limits versus adjustable quotas

A fixed constraint requires a data-model or application change. AWS cannot raise the item-size limit or make a transaction contain more items. An adjustable quota is an account setting: check the applied value for the correct Region in Service Quotas before treating the published default as your ceiling.

In the tables, Service Quotas identifies quotas you can request there. AWS Support identifies increases or allowlisting routed through support. Fixed means design around the value. Where AWS publishes a default without documenting self-service adjustment, the table says so rather than promising an increase.

Items and attributes

An empty set is invalid even though an empty list is valid. Empty String and Binary elements can appear inside sets, lists and maps. NULL is a supported attribute type; it is different from an absent attribute and cannot be a key.

How DynamoDB counts item size

Count the UTF-8 bytes of every attribute name, plus its value's stored representation. Multibyte characters can use more space than their character count suggests. Binary data is counted using its decoded length, although its base64 wire representation is larger. Numbers use DynamoDB's numeric representation, not simply the length of their JSON text.

Lists and maps add 3 bytes of container overhead and 1 byte per element, in addition to names and nested values. Booleans and nulls use 1 byte plus the attribute name. AWS's item-size calculation rules distinguish this item data from the additional storage overhead used for billing. Do not use the length of JSON.stringify(item) as an exact size validator.

Use the item size and capacity calculator when choosing how much data to keep together. Size also affects cost: writes round up in 1 KB units, and reads in 4 KB units. The 400 KB limit is a maximum, not a recommended item size.

Partition keys and sort keys

The key-length limits concern values, not the length of attribute names. Number keys follow the Number range and precision rules. For multi-attribute GSIs, use the documented composite-key constraints rather than assuming the base-table key layout applies unchanged.

Table and index quotas

The 100-attribute projection quota does not apply to ALL or KEYS_ONLY. Automatic projection of table and index keys does not use the user-specified projection allowance. The separate per-index limit comes from the Projection API.

LSIs must be created with the table and cannot later be added or removed. GSIs can be added later, but a new index is not queryable until it becomes ACTIVE. Follow the online index creation rules, and serialize table creation where secondary indexes are included. The CreateTable introduction says only one indexed table can be in CREATING, while its error description mentions up to 250 concurrent indexed-table creations. Because those statements conflict, do not rely on either as an unconditional current quota.

Is DynamoDB limited to 10 GB?

No. The 10 GB item-collection limit applies to tables with LSIs, not to the whole table. It includes the base-table data and LSI projections for one partition-key value. Without LSIs, an item collection can be split across physical partitions. A partition key that accumulates an unbounded history is therefore a particular risk when you choose an LSI.

Data operations and request sizes

The BatchGetItem API can return a successful response with unprocessed keys. Likewise, BatchWriteItem can return unprocessed operations. Retry only those entries with exponential backoff and jitter. Batches are not transactions, and batch writes do not support updates or per-item conditions.

The wire payload can exceed stored item size because of DynamoDB JSON type wrappers and base64 encoding. A batch must satisfy both the item-level constraints and the total request limit.

A TransactWriteItems idempotency token remains valid for 10 minutes after the first request completes. Reusing it with different request parameters during that window fails; after the window, the request is treated as new.

Transactions cannot contain two actions on the same item, including a ConditionCheck plus an Update. Attach the condition to the update instead. They must stay within one account and Region. An MREC global table does not replicate a transaction atomically to other Regions, and MRSC global tables do not support transactions. See the transaction guide for patterns that preserve the required atomic boundary.

PartiQL is another API surface over the same database constraints. Its statement, batch and transaction limits do not make SQL-style joins or arbitrary cross-item updates available.

Expression limits

The 255-byte substitution-token limit does not mean every String value stored through an expression is limited to 255 bytes. Account for the combined substitution size separately.

The 300-operator limit applies to condition, filter and update expressions. Comparators, logical keywords, functions and arithmetic operators count. In SET price = price + :delta, the + counts; the assignment = does not. Reserved attribute names remain usable through ExpressionAttributeNames aliases.

Throughput and partition limits

Units are not interchangeable with request counts. A strongly consistent read of up to 4 KB uses one read unit, an eventually consistent read uses half, and a transactional read uses two. A write of up to 1 KB uses one write unit, or two for a transaction.

The decrease quota starts with four available decreases at the beginning of the UTC day. One replenishes each hour, with at most four available at once. This allows 27 decreases across a full day. Tables and GSIs have independent allowances, but an update decreasing both fails if either has exhausted its allowance.

An on-demand table can also have a user-configured maximum throughput target. That is separate from its service quota and warm throughput, which describes throughput it can handle immediately. Increasing a quota does not fix a hot key or automatically pre-warm a table. Inspect the resource ARN and ThrottlingReasons before changing capacity; the throttling guide explains each limit category.

Control-plane API quotas

These APIs create or describe resources. Their quotas are independent of item read/write capacity and generally apply per account per Region. The AWS constraints page does not mark every API rate as adjustable through Service Quotas, so do not assume a throughput quota increase raises them.

A resource policy adds weight to mutable request accounting: two extra requests per KB of policy. For example, creating a table with a 5 KB policy counts as 11 requests. Deployment tooling should use bounded concurrency and backoff rather than retrying every resource at once. Backup API rates are documented in CreateBackup, DescribeBackup, DeleteBackup and ListBackups.

Streams, backups, PITR, TTL and bulk transfer

Exports require PITR and do not consume table read capacity. Imports do not consume write capacity. These operations have their own charges and concurrency quotas, so moving work away from the data plane does not make it quota-free.

TTL is asynchronous cleanup. Expired items can remain in reads and storage until deletion; filter them in the application when expiration affects correctness. The TTL guide includes the epoch conversion and setup details.

Global tables also have separate defaults: 400 MRSC global tables, 40,000 read/write units per second per table for either consistency mode, and 10 TB of new-replica backfill per destination Region per account per day. Coordinate increases across replica Regions through Service Quotas or AWS Support. A local table quota increase alone may not satisfy global-table replica creation requirements.

Vector index quotas

Native vector indexes are available on on-demand tables. Their limits are separate from GSI counts and ordinary read/write units. AWS lists the following in its service quotas page:

The byte-throughput limits describe data processed, not a fixed number of search requests. Vector dimensions, projected data and the amount examined per search affect throughput. Do not interpret TopK=100 as allowing only 100 vectors in the index.

Workarounds for the limits people hit most

Items larger than 400 KB

Store large binary objects or documents in S3 and keep their object key, metadata and version in DynamoDB. Alternatively, split a document into separately addressable items, or compress a payload that does not need attribute-level querying. Leave space for keys and future attributes. Compression removes the ability to filter the compressed content directly, and splitting creates a multi-item consistency problem you must handle explicitly.

Query or Scan results larger than 1 MB

Keep requesting pages using the returned LastEvaluatedKey as ExclusiveStartKey. A filter runs after DynamoDB evaluates a page, so an empty Items array is not an end-of-results signal. Continue until there is no continuation key. The pagination guide covers the implementation.

An API Limit counts evaluated items, not matches after filtering. If most evaluated data is discarded, fix the key condition or index rather than issuing larger scans. DynamoDB does not provide SQL joins, arbitrary ordering or offset pagination; its query shape follows the key design.

Transactions larger than 100 items or 4 MB

First reduce the atomic unit: keep the small set of records that must change together in one transaction. Move large immutable payloads elsewhere. If a workflow must span several transactions, use explicit progress records, idempotency and compensating actions. Splitting a transaction into batches does not preserve all-or-nothing behavior.

Hot partitions despite spare table capacity

Find the hot key and determine whether reads or writes are throttling. Cache repeated reads when staleness is acceptable, distribute writes across a suitable key space, or shard a write-heavy aggregate and combine results on read. Adaptive capacity and splitting help distribute load, but a single hot item still has a partition's limits. An LSI also prevents splitting an item collection across partitions.