DynoTable

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, batched with hard limits, and easy to amplify across hot partition keys. Migrations are application-level because there is no ALTER TABLE. This section covers batch APIs, return values, counters, uniqueness patterns, online reshaping, and the operational scar tissue when one partition key absorbs too much traffic.

What you can do after

  • 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 — BatchWriteItem caps, unprocessed keys, and why batch is not a transaction.
  2. Delete multiple items — batch delete vs staged delete in tooling; capacity per removed item.
  3. ReturnValues — ALL_OLD, UPDATED_NEW, and what comes back without a second read.
  4. Atomic counters — ADD updates and why read-modify-write loses under concurrency.
  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 — skewed keys, write spikes, and design fixes.
0 of 8 readQuiz
DynamoDB Batch Operations
DynamoDB batch operations — BatchGetItem reads 100 items per call, BatchWriteItem writes 25, why a batch is not a transaction, and how to retry leftovers.
Intermediate7 min read
How to Delete Multiple Items in DynamoDB
How to delete multiple items in DynamoDB — BatchWriteItem, TransactWriteItems, PartiQL batches and TTL — plus why there is no DELETE ... WHERE statement.
Beginner7 min read
DynamoDB ReturnValues: Get the Old or New Item
DynamoDB ReturnValues hands back the old or new item from PutItem, UpdateItem or DeleteItem without a second read — the five options and when each helps.
Intermediate5 min read
DynamoDB Atomic Counters: How ADD Works, and When It Doesn't
How DynamoDB atomic counters work with an ADD update expression, why they aren't idempotent, and when to reach for a conditional update instead.
Intermediate5 min read
DynamoDB Uniqueness on Multiple Attributes
How to enforce a unique constraint on multiple DynamoDB attributes — unique email AND username — with marker items and a condition-guarded TransactWriteItems.
Advanced6 min read
DynamoDB Migrations Without Downtime
DynamoDB migrations without downtime — how to add a new entity type and access pattern to a live table using lazy backfill, online GSIs, and dual-writes.
Advanced5 min read
DynamoDB Hot Partitions: How to Find and Fix Them
A DynamoDB hot partition is when one partition key absorbs a disproportionate share of traffic and throttles — how to spot it and design it out.
Intermediate9 min read
Knowledge checkTake the quiz
Check what you’ve learned in this section.

TransactWriteItems accepts up to 25 actions across up to 10 items, with a 4 MB transaction payload cap. Cancel reasons include ConditionalCheckFailed, TransactionConflict, and TransactionInProgress — each maps to a different retry strategy. BatchWriteItem also caps at 25 items but does not roll back siblings on failure — you handle UnprocessedItems in application code.

ReturnValues let you implement compare-and-swap without a follow-up GetItem. Atomic counters use ADD on a numeric attribute; uniqueness across attributes typically needs a separate "lock" item per unique value plus a conditional put on the main row. A migration that rewrites sort keys on a hot USER#popular partition can throttle writes for every user sharing that key's physical partition — schedule backfills with rate limits and watch the table's Overview for skew before you cut over.

Workbench steps

Download DynoTable with a paid trial to stage writes: edit an item, review the diff, and commit — the default path for put/update/delete. Batch delete via ⌘⇧⌫ commits directly; ⌘⌫ stages first. PartiQL INSERT/UPDATE/DELETE executes immediately with a warning toast, so treat PartiQL DML as a direct write path.

A table's Overview shows item counts and size estimates so you can see growth before a migration. The pricing calculator models write amplification when a migration doubles write traffic during dual-write.

Free read-only plans cover queries and exports; staging and commits require an active license or trial.