DynamoDB Capacity, Consistency & Indexes

Capacity mode changes management and billing, not the data model

DynamoDB supports on-demand and provisioned capacity modes. On-demand capacity removes the need to specify read and write throughput in advance and charges for request usage according to the service's pricing dimensions. Provisioned mode lets you define read and write capacity for a table and its applicable global secondary indexes, and DynamoDB auto scaling can adjust provisioned settings toward a target utilization. The primary-key model and API operations remain the same whichever capacity mode is selected.

Capacity planning still matters in on-demand mode because workload shape, hot keys, quotas, and scaling behavior can affect real applications. Provisioned mode makes throughput targets explicit, which can be economical for stable, predictable workloads but requires closer attention to consumed capacity. Choosing between the modes is therefore an operations and cost decision around traffic predictability, not a choice between two different DynamoDB engines.

Read consistency is chosen per supported operation

Eventually consistent reads are the default for DynamoDB read operations. A successful write may therefore take a short time before every eventually consistent read reflects it. For tables and local secondary indexes, supported read operations can request strong consistency with the ConsistentRead parameter when the application needs the most up-to-date successful writes. This stronger guarantee costs more read capacity for the same data size.

Global secondary indexes do not support strongly consistent reads; their reads are eventually consistent. This detail can decide whether a GSI is suitable for a correctness-sensitive access path. A common architecture uses a GSI for an alternate, scalable query path while reserving strongly consistent reads for access through the base table or an LSI where the application truly requires that guarantee.

• Strongly consistent read: one read unit for each 4 KiB chunk of item data read in the standard nontransactional case.
• Eventually consistent read: half a read unit for each 4 KiB chunk in the standard nontransactional case.
• Standard write: one write unit for each 1 KiB chunk of item data written.
• Transactional reads and writes consume different unit amounts; do not reuse nontransactional arithmetic for them.

Secondary indexes add query paths with different semantics

A global secondary index (GSI) can use a partition key and optional sort key that differ from the base table's primary key. It has its own index storage and, in provisioned mode, its own read/write capacity settings. Writes to the base table propagate to affected GSIs, so an index is not free: it adds storage, write propagation, and capacity considerations. GSI reads are eventually consistent and consume read capacity from the index rather than the base table.

A local secondary index (LSI) keeps the same partition key as the base table and defines an alternate sort key. It shares the base table's throughput and can support strong reads, but its lifecycle and structural constraints differ from a GSI. The design question is not 'which index is faster?' but whether the required alternate access pattern needs a different partition key, a different sort order within the same partition key, and which consistency/capacity semantics the application can accept.