The DynoStudio PartiQL dialect

DynoStudio's editor speaks a richer PartiQL than DynamoDB natively accepts. Everything the service can't run is lowered — translated into requests it can — and every lowering is disclosed: in the "Executes as" strip, in the editor's inline diagnostics, and in run status lines. Nothing executes in a way the UI doesn't explain.

If terms like partition key, sort key, GSI, Query, or Scan still feel slippery, read the DynamoDB basics first. This series is easier when the database model is already in your head.

The dialect is PartiQL-native: it extends the query language DynamoDB itself speaks, rather than emulating SQL through a script layer running over scanned rows. Every statement compiles to the operations the service actually executes — Query, BatchGetItem, TransactWriteItems — so results, semantics, and costs are the database's own.

-- a first query: read a tableSELECT * FROM "stage.Users"​-- further in: move money atomicallyBEGIN TRANSACTION;UPDATE "stage.Accounts" SET balance = balance - 100 WHERE accountId = 'A1';UPDATE "stage.Accounts" SET balance = balance + 100 WHERE accountId = 'B2';INSERT INTO "stage.Ledger" VALUE {'ledgerId': 'TX#123', 'amount': 100};COMMIT;

Three words used on every page

Each capability in this reference is tagged with where it actually executes. The tags matter because they predict cost and behaviour:

Find your entry point

You don't have to read this reference front-to-back. Every page stands alone, so start from the question that brought you here — each card below is a job you might be trying to do:

Prefer to build up from first principles instead? Read the cards in order — each guide builds on the ones before it, from a first SELECT to the control plane, and the prev/next links at the bottom of every page walk the same path. Already fluent? The keyword reference is the flat index — every keyword, operator, and function on one page — and each core statement has a dedicated page (SELECT, INSERT, UPDATE, DELETE, PROFILE TABLE, transactions) whose examples are quotable: every one carries a permanent deep link you can copy and share.

Guardrails, everywhere

Multi-request lowerings are capped, and every cap breach refuses with a named fix rather than running away with your bill. Each guide lists the caps for its own features — joins and subqueries in Joins, subqueries & sets, aggregates in Aggregates & profiling. Unknown tables, malformed subqueries and unbounded Scan subqueries are flagged in the editor before anything reaches the wire. On Professional, those caps are tunable per install (Settings → Querying) — raising one can increase a query's read cost. A couple of authoring conveniences (naming query parameters, tuning the caps themselves) are Professional features; running an already-saved parameterized function is free at every edition.