Review and undo your changes

A query tab’s History mode shows what you did to the tab’s table. The Commands view lists every operation that ran against the table. The Changes view lists the writes, shows what a single-item write did to the item attribute by attribute, and lets you undo it. Use it to check what an edit changed, or to put back a value you overwrote by mistake.

History mode requires the Pro plan, the same as Command history. Without it, the History key in the mode bar is locked and shows an upgrade prompt.

Open History mode

Click History in the query tab’s mode bar. Commands and Changes appear beside it as the mode’s two views. You can also run Switch to History from the command palette, which opens with ⌘ K on macOS or Ctrl + K on Windows and Linux.

The view you chose, the selected change, and the grouping stay as you left them when you switch modes or tabs.

Review the commands run on a table

Commands is the History page limited to the tab’s table. It has the same operation pills, status toggles, search box, date range, capacity strip, and cards, and the cards offer the same actions. The profile, region, and table selects are gone, because the table is fixed. See Command history for what each part does.

Review a change

Changes lists the writes to the table that ran, newest first. Each row shows the operation, how long ago it ran, and the item key it wrote, or a summary of the batch or statement.

Select a row to see the change. For a single-item edit, add, or delete, a table lists each attribute with its Before and After value. Rows are tinted by whether the change added, removed, or changed the attribute. Attributes the change left alone are hidden. To list them too, click Show N unchanged attributes. An add says The item did not exist before this change., and a delete says This change deleted the item.

Which writes appear

Changes lists every write to the table that History recorded, except a write that failed and a write that left the item as it was. That includes:

• Single-item edits, adds, and deletes from the grid.
• Batch writes, and pending changes committed with Commit as one transaction.
• PartiQL write statements.
• The entry a background job adds when it ends, such as a bulk write, an import, or an embeddings backfill.

Only a single-item edit, add, or delete keeps a before and after snapshot of the item. Every other write shows the command it ran instead of the attribute table, and cannot be undone. A snapshot is also missing when the item’s before and after images take more than 64 KB, when an edit moved an item onto a key that already held one, and for writes recorded before version 1.2.0.

A script, and an agent writing items through the MCP server, record no History entry, so their writes do not appear. A background job is the exception. A job adds its entry when it ends, whoever started it.

Undo a change

To undo a change, select it and click Undo. The status line next to the button says whether Undo is available.

Undo restores only what the change touched and leaves every other attribute as it is now:

• An edit. Each attribute the change touched gets its Before value back, and an attribute the change added is removed. Inside a map, only the keys the change touched are restored. A list, a set, or a scalar is restored as a whole value.
• An add. The item is deleted.
• A delete. The item is put back as it was.
• A key edit. One transaction deletes the item at its new key and puts it back at its original key.

An edit that touches more attributes than one conditional write can hold restores the whole item instead. Dynomatic offers that only while the whole item is unchanged.

What Undo checks first

Changes opens with the newest change selected. When a change is selected, Dynomatic reads its item with a strongly consistent read and compares it with what the change left. Undo is available only when the item is still in that state:

• For an edit, every attribute the change touched still holds the value the change wrote. Other attributes may have changed since.
• For an add, the whole item is unchanged.
• For a delete, no item holds the key again.
• For a key edit, the item at its new key is unchanged and no item holds its original key.

A number written as 1 or 1.0, and the order of a set, never count as a difference. Undo never creates an item for an edit, an add, or a key edit.

The undo write carries the same conditions as the read. If someone changes the item between the read and your click, DynamoDB refuses the write, nothing is written, and the Undo conflict dialog opens with The item changed while undoing. Nothing was written.

To check, the table’s profile must be connected. Undo uses that profile, never another one.

Read the status line

The status line says what the check found.

Status	What it means
Checking the current item...	The read is in progress.
The item is exactly as this change left it.	Undo is available.
Other fields have changed since. Undo only restores the fields this change touched.	Undo is available. It appears under the line above when attributes the change did not touch have changed.
N fields this change touched have changed since, so undo would overwrite newer data.	Undo is unavailable. The changed fields are listed under the message.
The item has changed since, so undo would overwrite newer data.	Undo is unavailable for an add, or for an edit that restores the whole item.
The item no longer exists, so there is nothing to undo.	The item was deleted after the change.
An item with this key exists again, so undo would overwrite it.	A deleted item’s key holds an item again.
The item at its new key (<key>) has changed since, so undo would overwrite newer data.	A key edit’s item changed after the edit.
An item with its original key (<key>) exists again, so undo would overwrite it.	A key edit’s original key holds an item again.
Could not read the current item: <message>	The read failed. Click Check again.
Connect to this table's profile to check the current item.	The profile is not connected.
No before and after snapshot was recorded. Only single-item edits, adds, and deletes keep one.	The write cannot be undone.
The item was too large to keep a snapshot.	The snapshot was over 64 KB.
This change touches more of the item than one conditional write can restore.	Even the whole-item undo is over DynamoDB’s expression limits.
Undone. The undo is recorded as its own change.	You undid this change in this session.

When the check finds a conflict, Check again reads the item again.

Compare and restore anyway

For most conflicts, Compare opens the Undo conflict dialog. It lists each field with its value Before, After this change, and Current, and highlights the fields that changed since.

For an edit, the dialog also offers Restore anyway. It sets every field the change touched back to its Before value, whatever the field holds now. Restore anyway still needs the item, and each map that holds a touched field, to exist. If one is gone, the button stays inert and the dialog names the field.

Confirm on a production table

On a table classified as Production, Undo and Restore anyway ask first. The confirmation lists each field the undo writes, with its Current value and its value After undo.

After an undo

The toast says Change undone. Refresh the results to see it. The grid does not read the table again by itself.

The undo is recorded as a change of its own, with exactly the fields it restored. To redo the original change, undo the undo. The same checks apply.

Group changes by item key

The Group by control above both views groups the list by the key each entry wrote or read.

• None keeps the flat, newest-first list.
• Partition key groups by the partition key value.
• Item groups by the partition key and sort key together. It is offered only on a table with a sort key.

A change groups under the item it wrote, and a key edit under its new key. In Commands, single-item reads and writes group the same way. A Query with an equality on the table’s partition key groups under that partition. Under Item, that partition has its own group, marked any sort key. Scans, PartiQL statements, batch writes, vector searches, and Queries on another key go in a No item key group at the end.

Each group header shows the key value, the entry count, and when the newest entry ran. A number key is marked N and a binary key B, so 1 and "1" read differently. Groups are ordered by their newest entry. Click a header to collapse or expand the group.

Show only the changes you can undo

Turn on Only undoable in the Changes view to hide every change you cannot undo now. The switch hides changes with no snapshot, changes you already undid in this session, and changes whose check found a conflict.

Turning the switch on runs the Undo check on every change in the list. Dynomatic reads each item once with strongly consistent reads, up to 100 items per request, and applies the same rules as the Undo button. Changes added to the table later are checked as they appear.

The first time you turn it on, Dynomatic asks first, because the check uses read capacity. The Check which changes can be undone? dialog says how many items it reads from which table, and about how many RCUs that costs. On a Production table, it adds that checking only reads items. Click Check and filter to go ahead. Dynomatic remembers the answer for every table and does not ask again. Cancel leaves the switch off.

While the check runs, the line above the list says Checking N changes.... A change still waiting stays in the list, with a note under it:

• Not checked yet. Select it to check.
• Checking...
• Could not be checked. Use Check again.

A change whose read failed stays in the list, and the line above it says N changes could not be checked. To read every change in the list again, click Check again on that line.

The selected change stays in the list when its check finds a conflict or you undo it, marked Cannot be undone now. It leaves once you select another change. Grouping applies to what the switch leaves, so empty groups disappear. When nothing is left, the view says Nothing to undo right now.