DynoTable
Beginner6 min read

How to View, Browse and Edit DynamoDB Data

Every "look at" or "change" you do to a DynamoDB table maps to one of a small set of API operations — GetItem, Query, Scan, PutItem, UpdateItem, DeleteItem. There's no relational table viewer underneath: "browsing a table" is literally a Scan, and "editing a row" is an UpdateItem against a primary key. Knowing which operation each click maps to is the difference between a cheap read and a full-table scan you didn't mean to run.

DynoTable is a GUI over exactly these operations — it shows you which one you're about to run, and the cost, before it hits the wire.

How to browse a DynamoDB table

Opening a table to "see what's in it" is a Scan — it reads every item in the table or index (AWS: "A Scan operation in Amazon DynamoDB reads every item in a table or a secondary index."). Fine for small tables; on a large one it's the classic cost footgun covered in query vs scan.

A single Scan returns at most 1 MB of data, then hands you a LastEvaluatedKey to fetch the next page — so "browse the whole table" is really a pagination loop (AWS: "A single Scan request can retrieve a maximum of 1 MB of data" and "the LastEvaluatedKey from a Scan response should be used as the ExclusiveStartKey for the next Scan request"). See pagination for how the cursor works and why offset-style page numbers don't exist here.

How to filter / scan DynamoDB data

The trap: a filter expression does not save you a scan. DynamoDB applies the filter after the read completes, so you pay for every item scanned — not just the rows you keep.

A filter expression is applied after a Scan finishes but before the results are returned. Therefore, a Scan consumes the same amount of read capacity, regardless of whether a filter expression is present. — AWS Scan docs

The response makes this visible: ScannedCount is "the number of items evaluated, before any ScanFilter is applied" while Count is what survived the filter (AWS). A high ScannedCount with a tiny Count is the signature of an inefficient scan.

How to query a DynamoDB table

A Query is the cheap, targeted read — but it requires a partition key. Per AWS: "You must provide the name of the partition key attribute and a single value for that attribute. Query returns all items with that partition key value. Optionally, you can provide a sort key attribute and use a comparison operator to refine the search results."

So a Query reads only the items under one partition key, optionally narrowed by a sort-key condition — never the whole table. No partition key, no Query: you're back to a Scan. That choice is the single most important cost decision in DynamoDB; the full breakdown is in query vs scan.

To assemble the KeyConditionExpression / FilterExpression without hand-writing the placeholder syntax, use the DynamoDB Expression Builder — it emits the exact names/values maps the API expects.

How to edit an item in DynamoDB

Editing one item is an UpdateItem against its full primary key. You don't rewrite the whole item — you supply an update expression naming only the attributes you're changing:

UpdateItem
  Key:              { "PK": "USER#42", "SK": "PROFILE" }
  UpdateExpression: SET email = :e, updatedAt = :t

Two facts that trip people up, both from the AWS items docs:

  • You must specify the entire primary key, not just part of it. On a composite-key table that's partition key and sort key. You can't "edit a row" by an arbitrary attribute — that needs a scan to find the key first.
  • UpdateItem is an upsert. "If an item with the specified key does not exist, UpdateItem creates a new item. Otherwise, it modifies an existing item's attributes." A typo in the key silently creates a new item instead of erroring.

How to delete an item

A DeleteItem, again keyed by the full primary key: "DeleteItem deletes the item with the specified key" (AWS). Same rule as edit — you need the whole key, so deleting "all rows where status = 'open'" isn't one call; you scan/query to find the keys, then delete each one. BatchWriteItem bundles up to 25 put/delete requests (AWS: "The BatchWriteItem operation can contain up to 25 individual PutItem and DeleteItem requests"), but each still targets one key — there's no DELETE … WHERE.

How to view nested / JSON data

DynamoDB items are stored in a type-tagged wire format (DynamoDB-JSON), where every value carries a one- or two-letter type descriptor (S, N, M, L, SS… — the full descriptor list is in the AWS data types docs). Plain JSON has no set type, so an array round-trips as a list (L), never a string set (SS) — a real conversion limitation, not a display bug. The full type map is in DynamoDB data types; to convert a DynamoDB-JSON blob to plain JSON and back, use the DynamoDB JSON converter.

Beyond browse-and-edit: querying that DynamoDB can't

Scan/Query/UpdateItem cover viewing and editing, but they can't analyse — DynamoDB has no JOIN, GROUP BY, or aggregate functions like COUNT/SUM, and PartiQL doesn't add them either: its SELECT grammar is just SELECT … FROM table [WHERE …] [ORDER BY …], with no join or grouping clause (AWS PartiQL SELECT reference), so each statement maps to a single Get/Query/Scan/Put/Update/Delete. DynoTable's SQL Workbench fills that gap by materializing your tables through DynamoDB's real query runtime and running SQL on top — SQL within DynamoDB's access-pattern rules — but for day-to-day browse-and-edit, the operations above are the whole toolbox.

FAQ

How do I view DynamoDB data without the AWS Console? Use a desktop GUI that issues the same Scan/Query calls. The AWS Console browses tables via paged scans; a dedicated client like DynoTable does the same but shows the consumed capacity and the operation you're running.

How do I edit a DynamoDB item? Issue an UpdateItem against the item's full primary key with a SET update expression naming only the attributes you're changing. In a GUI, inline-edit the cell — it compiles to that UpdateItem for you.

Why does filtering still cost a full scan? Because DynamoDB applies the filter after the scan reads the items. Filtered-out items are still read and metered. To cut cost, query by a partition key (or a GSI) instead of scanning.

Can I update many items at once? Not in one call. UpdateItem/DeleteItem each target a single primary key; there's no UPDATE … WHERE. You scan/query to collect the keys, then write each (up to 25 per BatchWriteItem).

Can I browse a DynamoDB Local table the same way? Yes — point the same GUI at the local endpoint. See DynamoDB Local.

Want to browse, filter and inline-edit DynamoDB tables — and run the SQL PartiQL can't? Download DynoTable.

Updated