The data grid
Browse, sort, filter and aggregate DynamoDB items in a fast, spreadsheet-style grid.
The data grid is Tablyne’s main view of a table: a fast, spreadsheet-style grid that renders the items returned by your current scan, query or PartiQL statement.
How the grid loads data
When you open a table, Tablyne runs a Scan and renders the first page. The grid shows two related counts in the status bar at the bottom: how many rows are currently shown versus how many have been loaded, plus the consumed RCU for the session.
Paging works in two ways:
- Load more — when DynamoDB returns a
LastEvaluatedKey, a load more button appears under the grid. Each click fetches the next page and appends it to what you already have. - Streaming — toggle ⚡ streaming in the filter bar to auto-fetch pages up to a configurable limit (default off). A safety cap stops runaway pagination on heavily filtered scans.
You control the page size (Limit, 1–1000) from the same filter bar. To change what loads, use the search panel — see /docs/search-query/ for the Query vs Scan builder and /docs/partiql/ for SQL mode.
Columns
Columns are discovered from the items as they load, so the set grows as more rows arrive. The partition key and sort key always lead, tagged with 🔑 PK and 🔸 SK; a TTL attribute is tagged ⏱ TTL.
| Action | How |
|---|---|
| Reorder columns | Drag a column header |
| Resize a column | Drag the header’s right edge |
| Hide / show columns | Use the columns menu (▦) in the bottom toolbar |
| Sort by a column | Click the header (click again to reverse) |
Sorting and filtering — on loaded rows only
This is the most important thing to understand about the grid:
Sort, quick-filter and aggregate act on the rows already loaded into the grid, not the whole table.
- Sort orders the loaded rows client-side using a natural (numeric-aware) comparison. It does not change the DynamoDB read order or fetch more data.
- Quick filter (the
⚲toggle) does a case-insensitive substring match across every value in each loaded row. It hides non-matching rows locally; it does not reduce read cost.
If you need the server to do the work — narrowing reads, paying only for matching items — push the condition into the Query/Scan builder or a PartiQL WHERE clause instead. See /learn/query-vs-scan/ for why a FilterExpression still reads every examined item.
Aggregations
Toggle the Σ button to open the aggregate bar. It computes spreadsheet-style column functions over the loaded rows:
| Function | Notes |
|---|---|
SUM, AVG, MIN, MAX | Numeric; non-numeric/blank cells are skipped, with a contributed / total hint |
COUNT | Counts non-null cells |
DISTINCT | Counts distinct values |
Add multiple functions side by side. Like sorting and filtering, aggregations cover only the loaded rows — the bar shows over N loaded items so the scope is always explicit.
Editing cells
Double-click a cell to edit it in place; the new value is coerced to match the existing type (number, boolean, or JSON for objects). Key columns (PK/SK) are read-only in the grid — to change a key, open the full editor. SQL mode is read-only, so cells can’t be edited while a PartiQL statement is active.
Edits don’t go to DynamoDB immediately. They are staged: edited cells highlight, and a pending-changes bar appears so you can commit everything together with Ctrl+S or discard. See /docs/staged-edits/ for the full model, and /docs/item-editor/ for editing a whole item.
Row actions
- New item —
＋ Rowopens the item editor prefilled with the table’s key skeleton. - Delete — select a row and press Delete (or use
🗑); the deletion is staged, not immediate. - Right-click a cell — a context menu offers copy value, copy item (as JSON), copy key, edit item and delete item.
Other views
The tabs at the bottom switch the same loaded data between Data, Schema, Entities, Map and Health (single-table-design tooling). Entities/Map/Health work over your loaded sample by default, with an opt-in scan all to compute real counts over the whole table.
Limitations to keep in mind
- Sort, quick filter and aggregations operate on loaded rows only — they never trigger extra reads or see un-fetched items.
- A
FilterExpression(from the search builder) is applied server-side but after the read, so it does not lower read cost. - Committing a cell edit writes the whole item back (
PutItemsemantics, last-write-wins) — see /docs/staged-edits/.