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.

Tip

A DynamoDB GUI hides the pagination loop behind a scroll or a "next page" button,
but it's still issuing one paged Scan per page. Watch the consumed-capacity
readout, not the row count, to know what you're spending.

How to filter / scan DynamoDB data

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.

Warning

"Filtering a table" in any DynamoDB GUI is a filtered Scan — it reads (and
charges for) the whole table, then throws most of it away client-side. If you're
filtering by an attribute you query often, that attribute probably wants a
GSI so you can Query it instead.

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.

On on-demand in us-east-1, opening a table to "browse" it runs a paged Scan
that bills 0.5 RCU per 4 KB eventually-consistent per item examined — a GUI
scroll through a 10 GB table of 1 KB rows is on the order of 2.5
million RCU if you load everything. A targeted Query on one partition key reads
only that item collection. Estimate browse vs query in the
pricing calculator.

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.

Note

Inline-editing a cell in a DynamoDB GUI compiles to an UpdateItem with a
single-attribute SET. The value's type tag matters — editing "37" as a string
(S) vs a number (N) writes a different item. See
DynamoDB data types for the wire format behind every cell.

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 analyze —
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?
There's no UPDATE … WHERE — each UpdateItem/DeleteItem targets a single primary
key. To change several items in one atomic request, TransactWriteItems applies up to
100 write actions (including Update) that all succeed or all roll back. Otherwise 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.