Staging & commit
Item edits, creates, and staged deletes go through a staging area before they touch DynamoDB. Think of it as a git staging area with a safety latch: changes accumulate as reviewable diffs, then ship as only when you commit.
Two paths skip the stage by design: PartiQL write statements run directly against your table with a warning, and ⌘⇧⌫ deletes the selected rows and commits in one step.
How it works
Each table has its own staging area, shared across every view of that table. When you save an item edit, create a row, or delete one, the change lands in the panel as a per-attribute diff — added, removed, and changed attributes shown side by side. Affected rows in the grid are tinted by operation:
- green — a new item (create)
- orange — an update (changed cells highlighted)
- red — a deletion (struck through)
Open the same table in two tabs and they show the same pending changes; close and reopen a tab and the stage is still there. Closing a tab never discards your staged changes.
Toggle the panel with ⌘⇧D. Drag its edge to resize it.
Reviewing changes
Each diff card shows exactly what will change:
- Scalars render old → new with red/green highlighting.
- Long strings show an inline word-level diff.
- Maps and Lists render as pretty-printed JSON (whole-attribute in v1).
Use a card's per-attribute Reject to drop a single attribute back to its original value. Reject every attribute and the whole change is discarded.
Committing
Commit to write your staged changes to DynamoDB:
- Commit N ships every staged change for that table — across all its tabs.
- Commit just this ships a single change from its card.
Commits go out as TransactWriteItems batches with optimistic-locking
conditions: an update only succeeds if the attributes still hold the values you
started from, a create only succeeds if the item doesn't already exist, and a
delete only succeeds if the item is still there. The
expression builder on this site composes the
same UpdateExpression and ConditionExpression shapes if you want to inspect them
outside the staging panel. Large stages are automatically chunked to stay within
DynamoDB's transaction limits.
The save chords from the editor apply here too:
- ⌘S — stage (no commit)
- ⌘⇧S — save & commit
- ⌘⇧X — discard all staged changes (with confirmation)
From a grid selection you can stage deletes without opening the editor:
- ⌘⌫ — stage a delete of the selected rows
- ⌘⇧⌫ — delete & commit the selected rows
Conflicts
Because commits use optimistic locking, a change committed by someone else after you staged yours is detected rather than silently overwritten. The card shows an inline banner:
- Drift — the remote item changed underneath you. Rebase onto remote refreshes the baseline so you can re-review, or Abort the change.
- Remote deleted — the item no longer exists. Abort the change.
- Network unavailable — the commit couldn't reach DynamoDB. Retry or abort.
A commit halts on the first failed batch — earlier successful batches stay written, the rest are not attempted, and the failures surface as conflicts to resolve.
What blocks commits
Editing, staging, and committing all need a Trialing or Active license. A state blocks the whole path, not just the commit — it unlocks again once the app is back to an active state.