The PartiQL editor
Run PartiQL against DynamoDB with autocomplete; read-only and never auto-runs.
Tablyne’s SQL mode is a PartiQL editor with syntax highlighting and autocomplete, for running SQL-style statements directly against DynamoDB.
Opening SQL mode
Toggle the SQL button at the top of the search panel. The editor opens seeded with a safe default for the current table:
SELECT * FROM "orders"Switching between Busca and SQL never runs anything on its own — flipping modes is free and won’t fire a SELECT * scan. This is deliberate: a stray mode switch should never cost you a full-table read.
Running a statement
Nothing executes until you explicitly run it:
- Click ▶ run, or
- Press Ctrl+Enter in the editor.
Until you run, the grid stays empty and shows edit the query and run (Ctrl+Enter). Results replace the grid; pagination uses PartiQL’s NextToken, so the load more button works the same as in Busca mode. Every run is recorded in your per-table history — see /docs/saved-queries-history/.
Autocomplete
As you type, the editor suggests:
- Keywords —
SELECT,FROM,WHERE,AND,OR,BETWEEN,IN,ORDER BY,INSERT,UPDATE,DELETE, and more. - Functions —
begins_with(),contains(),attribute_type(),size(). - The current table name, quoted (
"orders") as PartiQL requires. - Attribute names discovered from the loaded rows.
Pick a suggestion to insert it; functions insert with parentheses ready for arguments. Autocomplete is case-insensitive and matches by prefix, so typing beg surfaces begins_with() and typing the start of an attribute name surfaces that attribute. The editor follows the active app theme, so keywords, strings and function names stay readable in any color scheme — see /docs/themes/.
A typical query that pins the partition key and filters within a partition looks like this:
SELECT * FROM "orders"
WHERE pk = 'USER#42' AND begins_with(sk, 'ORDER#')Because the partition key is pinned, DynamoDB serves this as a Query. Drop the pk = clause and the same statement becomes a full-table Scan.
Read-only by design
SQL mode is read-only in Tablyne. It runs your statement, but the grid won’t stage or write changes from it, and cell editing is disabled while SQL mode is active.
Even though PartiQL’s grammar includes INSERT, UPDATE and DELETE, Tablyne’s grid is built around its staged-edit model, which it can’t reconcile with arbitrary write statements. So the editor focuses on SELECT: you read with PartiQL, and you write through the grid, the item editor, import, or bulk operations — all of which give you a reviewable, committable change set.
A SELECT in PartiQL is still a Query or a Scan under the hood. If your WHERE clause pins the partition key, DynamoDB runs a query; otherwise it’s a scan. Use the Busca builder when you want Tablyne to show you that routing decision and cost up front.
Writing it down
A few helpers sit next to the run button:
- Saved queries — name and store a statement for reuse across sessions.
- History — revisit the statements you’ve run against this table.
- Collections — group related requests together.
See /docs/saved-queries-history/ and /docs/collections/.
Generating it elsewhere
Once a SELECT works, Gerar código turns it into an ExecuteStatement call for the AWS SDK (JS/TS, Python) or the AWS CLI — see /docs/code-generation/. If you have an AI provider configured, the AI panel can draft PartiQL from a natural-language prompt; see /docs/ai-query/.
Limitations to keep in mind
- Read-only: write statements aren’t executed against the table through this editor — use the grid’s staged edits, import, or bulk for writes.
- Never auto-runs: you must press run / Ctrl+Enter; switching modes does nothing on its own.
- Grid-side sort, quick-filter and aggregation still act on loaded rows only, not the whole result set on the server.
- Autocomplete for attributes is based on loaded rows, so attributes not yet seen won’t be suggested.