TopolearnCapacity decides your bill and your throttling behaviour; consistency decides what a read can return.
DynamoDB meters work in units:
- one read unit = one strongly consistent read per second of an item up to 4 KB (eventually consistent reads cost half)
- one write unit = one write per second of an item up to 1 KB
- sizes round up per item: a 5 KB write costs 5 units, a 5 KB strong read costs 2
- transactional reads and writes cost double
In on-demand mode you pay per request and DynamoDB absorbs spikes instantly up to double the previous peak, ramping beyond that; you can set maximum throughput to cap cost. It is the recommended default. In provisioned mode you set RCU and WCU, usually with auto scaling; it is cheaper for steady, predictable traffic. You can switch modes.
When a request exceeds capacity, it is throttled with ProvisionedThroughputExceededException or ThrottlingException. The SDKs retry with backoff automatically; persistent throttling usually means a hot key rather than too little total capacity.
Consistency: by default GetItem, Query and Scan are eventually consistent and may miss a write from the last moment. ConsistentRead=True gives a strongly consistent read reflecting all successful writes, at twice the cost; it is not available on GSIs or in Streams.
Example
# Capacity arithmetic (per item, rounded up):
#
# item 3 KB strong read ceil(3/4) = 1 RCU
# item 3 KB eventual read 0.5 RCU
# item 9 KB strong read ceil(9/4) = 3 RCU
# item 2.5 KB write ceil(2.5/1) = 3 WCU
# item 2.5 KB transactional write 2 * 3 = 6 WCU
#
# Query reading 40 items of 1 KB (40 KB total, strong): 40/4 = 10 RCU
# (a Query sums item sizes first, then rounds up to 4 KB)
import boto3
table = boto3.resource("dynamodb").Table("Orders")
r = table.get_item(Key={"customer_id": "c1", "order_id": "o1"},
ConsistentRead=True, ReturnConsumedCapacity="TOTAL")
print(r["ConsumedCapacity"]) # {'TableName': 'Orders', 'CapacityUnits': 1.0}Remember
- Reads are metered in 4 KB, writes in 1 KB steps
- Eventual reads cost half; transactions cost double
- On-demand is the default choice; provisioned suits steady traffic
- Strong reads cost 2x and are unavailable on GSIs
Watch out for
- Storing large, rarely read attributes in frequently written items, multiplying write cost by item size.