Querying

Command history

Find, inspect and re-run every DynamoDB operation Dynomatic has sent for you.

Every DynamoDB operation the app runs is recorded automatically, with the expression it sent, the capacity it consumed and how long it took. Use it to work out what a slow query actually asked for, to catch an accidental full table scan, or to run something again without rebuilding it. Command history requires the Pro plan.

The command history page with its filter bar and a timeline of operation cards

Open it

Press Cmd+5 (Ctrl+5), or click History in the nav rail. The dashboard’s Recent Operations card shows the newest five entries and links through with Full history >.

To see the history of one table, or to undo a change, use the History mode of a query tab instead. See Review and undo your changes.

Narrow the list

Filtering happens in two stages. First the filter bar, then the pills.

  • The search box matches table names, indexes, expressions, error text, profile names and attribute values.
  • The profile, region and table selects each scope to one value.
  • The date range offers All time, Last hour, Today, Last 7 days and Last 30 days.

Below the bar, operation pills carry live counts for All, Query, Scan, PartiQL, Vector Search and Writes. Three status pills, Starred, Warnings and Errors, appear only while their count is above zero.

A capacity strip between the filters and the timeline totals the read and write units the listed operations consumed, with a per-table and per-index breakdown. See Know what a read costs.

Read a card

Each card is one operation, color-coded by kind. It shows the latency (colored once it crosses a threshold), the item count, the read or write units consumed, the workspace it ran in, an environment dot for that workspace’s tier, and a summary of the expression.

Click a card to expand it. The detail adds the error text where there was one, the raw PartiQL statement, the attribute values that were bound, the fields a write changed, and a wasteful-scan warning when the operation scanned more than twice the items it returned. Three actions sit at the bottom, Re-run, Copy and Delete.

A vector search records a SearchVectors card instead. It names the index and where the query vector came from, either an item’s key, an inline vector with its dimension count, or the text that was embedded and the model that embedded it. In place of read units it reports the request size in bytes, because a vector search costs by request size rather than by capacity. These cards offer no Re-run.

A background job adds one entry when it ends. Its card carries a BulkWrite, Import or Embeddings badge, the label the Jobs panel showed, the number of items it wrote, how long it ran and the write units it consumed. A failed job is listed under Errors, and a job that was cancelled or finished with some items failed is listed under Warnings. The capacity strip counts the job’s units as writes on the Not broken down row, because a job reports the table’s total rather than a split by index. A native DynamoDB import adds no entry, because DynamoDB writes that table, not Dynomatic. Job cards offer no Re-run.

Re-run an operation

Re-run opens a new query tab for the entry’s table and executes it straight away. It re-establishes that workspace’s session first if the credentials have lapsed, including an SSO or MFA prompt, and it runs even when the table’s auto-scan setting would otherwise hold the tab back.

Key and filter expressions are parsed back into builder pills, so the re-run lands as an editable query rather than an opaque replay.

When a recorded condition cannot be restored, for example because its value no longer passes the builder’s checks, the tab opens with the conditions that came back and runs nothing, even with auto-scan on. Running it would read more than the original query did. A warning names the fields, for example Opened without running. The recorded condition on <fields> could not be restored, so running now would read more than the original query. When the stored command cannot be read at all, the warning says the recorded query could not be read.

Star what matters

Add to favorites on a card stars it. Starred entries survive Clear History, and the Starred pill filters to them.

Clear history

Clear History opens a confirmation offering Clear filtered (N) while a filter is active, and Clear all history. Starred entries are preserved either way.

History keeps the last 500 entries. Every entry belongs to the workspace it ran in, and removing a workspace removes its entries with it.

Last updated on