Edit many rows at once

The Bulk edit dialog sets attributes to a typed value, or removes them, on many rows in one pass. It works on the rows you selected or on every row the current filter matches. The dialog writes nothing itself. Changes to selected rows become pending changes in the data grid, and an edit of every matching row runs as a background job.

Note: Bulk edit requires the Pro plan. Without it, the Bulk edit buttons show an upgrade prompt.

Open Bulk edit

Open the dialog from any of these places:

• The action bar above the grid, on a Filters result. Click the Bulk edit button beside Add row.
• The selection row of the action bar, after you select rows. Click Bulk edit N rows.
• The command palette. Press ⌘ K on macOS or Ctrl + K on Windows and Linux, and choose Bulk edit rows.

Bulk edit is not offered on a read-only result set. On PartiQL, schema, and vector search results, it edits selected rows only.

Choose the rows

The Rows control at the top left sets the scope:

• N selected rows edits the rows you selected in the grid.
• All matching the filter edits every row that the tab’s Filters query matches. It is available only on a Filters result.

The dialog opens on the selected rows when you have a selection, and on all matching rows when you do not.

With All matching the filter, a line under the control says how many rows match. When the grid has not loaded every match, it reads N rows are loaded, and more match the current filter. The job still edits every matching row, not only the loaded ones. If the filter reads a secondary index, a second line warns that the index is eventually consistent, so a row that starts to match while the job runs can be missed.

Add the changes

Each change in the Changes list is one operation on one top-level attribute. To add another, click Add change.

1. Choose Set or Remove.
2. Click the attribute field and pick an attribute. The menu lists the attributes the rows carry, with their types. To use a name the rows do not have yet, type it and choose + Use “name”.
3. For Set, choose the value type and enter the value. The types are String, Number, Boolean, and Null.

Set can target only attributes that hold a String, Number, Boolean, or Null. An attribute of any other type, such as a map or a set, can only be removed. Remove can target any attribute.

The dialog refuses a change, and names the reason under it, in these cases:

• The attribute is part of the table’s primary key: The primary key can't be bulk edited.
• Another change already targets the same attribute.
• A Number value is not a valid DynamoDB number.

Edit a secondary index key

You can set or remove a GSI partition or sort key, or an LSI sort key, even when Lock Key Editing is on for the table. A change to an index key shows a note that names the index:

• Set reads This is a key of the <index> index. Each edited row moves to its new key in that index.
• Remove reads This is a key of the <index> index. Each edited row leaves that index.

A Set on an index key must match the key’s declared type, so it accepts only String or Number. An empty string is refused, because DynamoDB rejects an empty index key.

Check the dry run

The Preview (dry run) pane on the right shows what the changes do to the rows in scope before anything is written. Its header counts the rows that change, the rows that already have these values, and the rows skipped because they are marked for deletion. A row marked for deletion is never brought back.

Below the header, each changed row shows its key and every changed attribute, with the old value struck through and the new value after it. An attribute the row does not hold reads absent. The pane lists the first 50 changed rows and then says how many more there are.

With All matching the filter, the preview covers only the rows the grid has loaded.

Stage changes to selected rows

For selected rows, the primary button reads Stage N changes. Click it to add the changes to the tab’s pending changes. They stack on top of any edits already pending on those rows. Nothing is written until you commit, so you review, revert, and commit them as you would any grid edit. See Review and commit.

Apply to every matching row

For All matching the filter, the primary button reads Apply to N rows, or Apply to N+ rows when more rows match than the grid has loaded. Click it to start a background job. The dialog closes, and the Background jobs panel shows the job as it runs. The job reads every matching row itself and sets or removes the attributes on each. Nothing is staged. A row deleted before the job reaches it is skipped, never recreated.

The cost line beside the buttons gives an approximate total in write capacity units, the write rate, and about how long the job takes, in minutes and seconds: About <n> WCU at up to <n> WCU/s, about <m:ss>. Each row is costed at the table’s average item size. When the grid has not loaded every match, the line assumes every item in the table matches, by the item count DynamoDB reports. If the job would be refused, the line says why.

Apply stays unavailable, with the reason announced, until the estimate for your latest changes arrives. It is also held when every matching row already has the values, or when the tab is not bound to a workspace. To follow, pause, or cancel the job, see Background jobs.

Commit as one transaction

The pending changes popover on the action bar’s diff chip and the Pending Changes sheet both have a Commit as one transaction checkbox. When it is checked, a commit sends every pending change in one TransactWriteItems call, so all of them are written or none are.

DynamoDB limits what one transaction can hold, and the checkbox says before you commit when your changes do not fit:

• A transaction holds at most 100 writes. An edit to a primary key attribute counts as two writes, because it deletes the old item and puts the new one.
• A transaction can write each item only once, so two changes to the same item are refused.

While either limit is exceeded, the commit button in the popover and in the sheet does nothing. Commit fewer changes, or clear the checkbox.

If DynamoDB refuses the transaction, no change is written and every change stays pending. An alert reads Transaction failed. No changes were written., with one more alert for each refused change that names the item’s key and the reason. If DynamoDB never confirms the result, for example after a timeout, the alert says the transaction may or may not have been written. Refresh the table and check before you commit again.

The checkbox setting applies to the current tab until you quit the app. It requires the Pro plan. Command history records the commit as one TransactWrite.