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.Users" SET balance = balance - 100  WHERE pk = 'User#9' AND sk = 'PROFILE';UPDATE "stage.Users" SET balance = balance + 100  WHERE pk = 'User#12' AND sk = 'PROFILE';INSERT INTO "stage.Outbox" VALUE {'pk': 'Outbox#transfers', 'sk': '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 core guide cards in order — each builds on the ones before it, from a first SELECT to the control plane. The OpenSearch and hybrid references stand beside that path when your workload leaves a single DynamoDB plane. Already fluent? The keyword reference is the flat index, and each core statement has a dedicated page (SELECT, transactions, vector indexes, backup and restore, OpenSearch, hybrid queries) with quotable deep links.

Guardrails, everywhere

Multi-request lowerings are capped, and every breach refuses with a named fix rather than running away with your bill. Each guide lists its own limits — joins and subqueries, aggregates, vector top-k, OpenSearch offset, and the 5,000-row cross-plane leg cap. Unknown targets, malformed subqueries and unbounded Scan subqueries are flagged before the wire. On Professional, the ordinary lowering caps are tunable per install (Settings → Querying); OpenSearch and hybrid execution are themselves Professional capabilities.