AI query generation (NL to PartiQL)
Describe what you want in plain language and get a PartiQL statement, schema-aware and cost-conscious.
Type what you want in plain English (or any language your model speaks) and Tablyne turns it into a single, valid DynamoDB PartiQL statement.
Where to find it
The AI panel lives in the data view’s search bar, alongside the query builder and the PartiQL editor. Once you’ve connected a provider in AI setup, an AI input row appears with a provider selector, a prompt box, and a Generate button.
If no provider is configured yet, the panel shows a shortcut that opens Settings → AI so you can add one.
Writing a prompt
Just describe the result you want against the current table:
items where status is active and created in the last 7 days
top 20 orders for customer 4821 sorted by date
all users whose email is missingPress Enter or click Generate. Tablyne sends your prompt plus the table’s schema to the model and streams back a PartiQL statement.
Schema-aware generation
Tablyne gives the model exactly enough context to write correct PartiQL — and nothing more:
- the table name,
- the partition key and sort key names,
- the list of known attribute names.
No item values are sent. See the privacy note in AI setup for the full detail. Because the model knows your keys and attributes, it quotes the table name and string literals correctly and references real attributes rather than guessing.
Cost-conscious by design
The system prompt explicitly instructs the model to prefer a Query over a Scan whenever the request can be satisfied by filtering on the partition key (with = or IN). A Query reads only the matching partition; a full-table Scan reads every item and is far more expensive on a large table.
So a prompt like “orders for customer 4821” will tend to produce a partition-key Query rather than a Scan with a filter. You can always edit the generated statement before running it.
| Pattern | What the AI favors | Why |
|---|---|---|
| Filter on the partition key | Query (WHERE pk = …) | Reads one partition |
| No partition-key constraint | Scan | Unavoidable, but flagged as costlier |
| Membership on the key | Query with IN | Still partition-scoped |
Per-query model switch
The provider selector defaults to your global default provider, but you can switch it per query without changing the default. Each option shows the provider name and its model (the default is marked with a star). This lets you, for example, use a fast cheap model for simple lookups and a stronger model for a gnarly request — all in the same session, with no settings round-trip. Switching here only affects the current panel; your global default stays untouched.
It stages, it never auto-runs
This is the important safety property: the generated PartiQL is placed into the editor — it is never executed automatically.
After generation you get a normal PartiQL statement in the editor where you can:
- Read what the model produced,
- Edit it (tighten the filter, fix a literal, add a
LIMIT), and - Run it yourself when you’re satisfied.
Nothing touches your table until you press run. Markdown code fences are stripped from the model’s output automatically, so you get clean PartiQL ready to inspect.
Example
Prompt:
active products in category electronics under $500Generated (and staged into the editor):
SELECT * FROM "Products"
WHERE category = 'electronics'
AND status = 'active'
AND price < 500Review it, adjust if needed, then run.
Learn more
For PartiQL syntax, supported clauses, and how Query vs Scan pricing works in practice, see: