Browse and edit DynamoDB tables without the AWS console

Build me an internal data console for Amazon DynamoDB that my team opens instead of the AWS console. It needs to be quick to move around in, safe by default, and readable by people who do not write DynamoDB expressions every day.

The landing view lists every table in the connected account using List Tables, with a search box to filter the list by name. Clicking a table opens it. Keep the table list reachable at all times so switching between two tables never means losing what I was looking at and never means going back a screen.

When a table is open, show a header built from Describe Table: the partition key and sort key names and types, any secondary indexes, the approximate item count, the table size, and the table status. Keep it compact and always visible while I scroll.

Below the header, show a spreadsheet-style grid of items, one row per item and one column per attribute, with column selection and sorting. Fill it two ways. If I supply a partition key value, and optionally a sort key condition, run Query with a KeyConditionExpression. If I am exploring, run Scan with an optional FilterExpression plus ExpressionAttributeNames and ExpressionAttributeValues. Make the filter input a real editor with room to type and syntax help nearby, not a tiny single line box. Show which mode produced the rows currently on screen, and say plainly when a scan is reading the whole table.

Paging is a Load more button at the bottom of the grid. Hold on to the LastEvaluatedKey the previous Query or Scan returned and send it back as ExclusiveStartKey on the next otherwise identical call, appending the new page to the rows already on screen rather than replacing them. When the response comes back without a LastEvaluatedKey, tell me we have reached the end instead of leaving a button that does nothing.

Clicking a row opens a detail drawer that re-reads the record with Get Item using its primary key, so I am always editing the current version. The drawer renders the item as a friendly form: strings as text inputs, numbers as number inputs, booleans as switches, lists and maps as nested collapsible groups, string and number sets as tag inputs, and nulls as an explicit empty state. Never show the tagged attribute-value wire format in the interface. Convert tagged values into plain form values when reading and back into correctly tagged values when writing, remembering that numbers travel as strings.

From the drawer I can save changes with Update Item, using an UpdateExpression built only from the fields I actually touched. I can duplicate the record into a new one, or create a record from scratch, with Put Item. I can delete it with Delete Item behind a confirmation that makes me type the record key before the button turns on. The grid also has row checkboxes and a bulk delete that chunks the selected keys into Batch Write Item calls of at most 25 and reports anything that comes back unprocessed.

Add an Advanced tab where I can write a raw PartiQL statement and run it with Execute Statement (PartiQL), showing the returned rows in the same grid and paging with the NextToken it returns. Treat any statement that is not a SELECT as a write, so it respects the edit lock and gets logged like every other change.

Saved queries are the first thing that makes this worth opening daily. Let me name and save any lookup or exploration setup, including the table, the mode, key values, the filter expression with its attribute names and values, the selected columns and the sort, and pin it to the table it belongs to. Saved queries persist in the app and are visible to the whole team, run with one click, and can be marked as the default that loads automatically when someone opens that table.

The second thing that makes it worth opening is safety. The app starts read only. Every write control is visible but disabled until the user flips an Enable edits switch in the header, and that switch resets to off each time the app is opened. While edits are off, the drawer is a viewer, bulk delete is unavailable, and non-SELECT statements are refused with a clear message rather than an error.

Append every write to an audit table in the same DynamoDB account using Put Item. Each audit record carries a unique id, a timestamp, the signed-in user, the table name and the key of the record that changed, the operation (update, create, duplicate, delete, bulk delete or statement), the value read before the write, and the value after it. Let me choose which table is the audit table in a small settings area, and surface an item's recent history inside its detail drawer. If the audit write itself fails, say so loudly instead of letting the change go unrecorded.

Overall feel: a dense but readable grid, a sticky header, keyboard friendly navigation, and no long blank spinners on tables with many attributes. The goal is that anyone on the team can answer a question about production data in a few seconds without opening AWS, and cannot break anything by accident on the way.