Writes & Operations

You assume DynamoDB enforces uniqueness like a SQL unique index, deploy without a condition expression, and discover duplicate accounts in production. There is no cross-attribute constraint, only atomic writes you design yourself.

Writes are item-scoped and batched under hard limits, and one busy partition key can throttle while the rest of the table idles.

Migrations are application-level because there is no ALTER TABLE. This section covers batch APIs, return values, counters, uniqueness patterns, online reshaping, and hot partitions.

What this section teaches you to do

• Use BatchWriteItem and batch delete within the 25-item / 16 MB limits without silent partial failure.
• Implement atomic counters and multi-attribute uniqueness with conditional writes.
• Plan a zero-downtime migration with dual-write or backfill patterns.
• Spot a hot partition from write distribution and key choice before throttling.

Reading order

1. Batch operations: BatchGetItem and BatchWriteItem caps, unprocessed keys, and why a batch is not a transaction.
2. Delete multiple items: BatchWriteItem, transactions, PartiQL and truncate, and why there's no DELETE … WHERE.
3. ReturnValues: ALL_OLD, UPDATED_NEW, and what comes back without a second read.
4. Atomic counters: ADD updates, and why a retried increment counts twice.
5. Unique multiple attributes: uniqueness items and conditional puts that reject duplicates.
6. Migrations: reshape keys and GSIs while traffic is live; no schema migration button.
7. Hot partition: finding the hot key, write sharding, and caching hot reads.

TransactWriteItems accepts up to 100 actions, no two on the same item, with a 4 MB aggregate cap.

A canceled transaction lists a reason per action, such as ConditionalCheckFailed, TransactionConflict or ThrottlingError, and each maps to a different retry strategy.

BatchWriteItem caps at 25 requests and does not roll back siblings on failure, so you handle UnprocessedItems in application code.

A condition expression gives you compare-and-swap; ReturnValues hands back the old or new item without a follow-up GetItem.

Atomic counters use ADD on a numeric attribute. Uniqueness across attributes needs a separate "lock" item per unique value, written with the main row in one conditional transaction.

A migration that backfills a hot USER#popular partition can throttle writes to that key.

Pace the backfill to a write budget you measure with ReturnConsumedCapacity, and alarm on WriteKeyRangeThroughputThrottleEvents (writes throttled by partition limits). The migrations guide shows the guarded sweep.

Workbench steps

In DynoTable, writes stage by default: edit an item, review the diff, and commit. PartiQL INSERT/UPDATE/DELETE stages too, with a Commit changes / Stage changes split button. ⌘⌫ stages a delete; ⌘⇧⌫ deletes the selection directly.

A table's Overview shows DynamoDB's item-count and size estimates, so you can see growth before a migration.

To see which keys are hot, use CloudWatch Contributor Insights in the AWS console. The pricing calculator models the extra writes while a migration dual-writes.

Free read-only plans cover queries and exports; staging and commits require an active license or trial. Download DynoTable and start a free 30-day trial, no credit card, to stage writes against your own tables.