Search: Query vs Scan builder
A single condition builder that auto-routes to Query or Scan and shows the cost.
Tablyne’s Busca (search) mode is a single condition builder that lets you describe what you want, then automatically decides whether it can run as a cheap Query or must fall back to a Scan — and tells you which before you run it.
One builder, no Query/Scan toggle
Most tools make you choose Query or Scan up front and then juggle key conditions separately from filters. Tablyne removes that decision. You add conditions as attribute · operator · value rows, and the router classifies each one:
- A condition on the partition key with
=becomes a key condition (the basis of aQuery). - A condition on the sort key with a key-valid operator (
=,<,<=,>,>=,between,begins_with) rides along in the key condition — but only if the PK is also pinned. - Everything else becomes a
FilterExpression.
Each row shows a role chip — 🔑 PK, 🔸 SK, or filter — so you can see how it’s being interpreted as you type.
Query vs Scan, decided automatically
The badge above the run button shows the routing decision live:
| Badge | Meaning |
|---|---|
| ● QUERY | The partition key is pinned with =, so Tablyne issues a Query against that partition (cheap, reads only matching items + any filtered-out ones in range). |
| ● SCAN | No partition key is pinned, so Tablyne must Scan the table and apply your conditions as filters. |
A sort-key condition without a partition key can’t be a key condition (DynamoDB forbids it), so Tablyne demotes it to a filter rather than silently ignoring it — the read still respects it, just at scan cost.
This is why a FilterExpression doesn’t save money: filters are applied after items are read, so you pay read capacity for everything examined, not just what’s returned. See /learn/query-vs-scan/ for the full cost story.
Operators
The operator set depends on the attribute’s role. Key conditions are limited to what DynamoDB allows on a sort key; filters get the full set:
| Group | Operators |
|---|---|
| Sort-key (key condition) | = < <= > >= between begins_with |
| Filter (any attribute) | the above plus <> in contains attribute_exists attribute_not_exists attribute_type |
between reveals a second value field; in accepts a comma-separated list; attribute_exists / attribute_not_exists take no value.
Querying an index
If the table has GSIs or LSIs, an index selector appears. Pick one and the builder re-seeds with that index’s keys, so a Query runs against the index instead of the base table.
When a plain filter condition is actually the partition key of another index, Tablyne suggests it: status is the PK of byStatus — use that index? One click switches you over and turns an expensive scan into a query.
Running
Click Executar or press Ctrl+Enter. Results replace the grid and start a fresh page count. Incomplete condition rows (an empty value, a half-filled between) are ignored so a default SK row you haven’t filled doesn’t break the query.
The same builder powers the scope picker in bulk operations, so a bulk runs over exactly the items your search matched.
Limitations to keep in mind
- A
FilterExpressionnarrows what’s returned, not what’s read — it does not reduce read cost or latency on a large table. - Sort, quick-filter and aggregations in the grid still act on loaded rows only; the search builder controls the server-side read, but client-side grid operations are separate (see /docs/data-grid/).
- Only one partition-key
=condition forms a query; extra PK/SK duplicates fall through to filters.