# 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](https://dynostudio.dev/docs/dynostudio-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.

```sql
-- a first query: read a table
SELECT * FROM "stage.Users";

-- further in: move money atomically
BEGIN 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;
```

> **Want to run what you read?:** Every example in the series queries three sample tables you can have loaded in two minutes — free and offline on DynamoDB Local, or imported straight into the studio. [Set up the sample tables](https://dynostudio.dev/docs/dynostudio-partiql-setup/) once, and the queries the pages print return the rows the pages show.

## 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:

- **Native** — DynamoDB executes it server-side. The statement you write is (or compiles directly to) the request the service runs.
- **Lowered** — The studio translates it into native requests; any client-side work is disclosed in the "Executes as" strip and run status lines.
- **Kanject** — A convention extension beyond the PartiQL spec — e.g. key templates like 'Customer#{CustomerId}' that understand your schema.

> **The one cost rule:** On ordinary table and GSI reads, the shape of your query is the shape of your bill. A **partition-key equality or `IN` list** stays a cheap **Query**; anything else is a **Scan** that reads — and **bills** — every item in the table. Lowered features (joins, aggregates, subqueries, set operations) work after those reads, so every row they match, filter, fold, or `OFFSET`-skip is still billed. Native vector-index reads are the explicit exception: they lower to byte-metered `SearchVectors`, with their own receipt. The "Executes as" strip tells you which path you got every time.

## 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:

- **["Show me my data"](https://dynostudio.dev/docs/dynostudio-partiql-basics/)** — Your first SELECT against a table or a GSI, choosing and computing columns — and how to read the "Executes as" strip.
- **["Fetch exactly these items"](https://dynostudio.dev/docs/dynostudio-partiql-reads/)** — The WHERE reference: key conditions vs filters, keeping a read a cheap Query instead of a full-table Scan, sorting and paging.
- **["Find the nearest matches"](https://dynostudio.dev/docs/dynostudio-partiql-reads/#vector-similarity-search)** — Top-k vector similarity with VECTOR_DISTANCE: descriptor-validated filters, dimensions, projection, ordering, readiness, and byte-metered cost.
- **["Search words, facets or geography"](https://dynostudio.dev/docs/dynostudio-opensearch-index/)** — OpenSearch projections and reads: MATCH, exact filters, highlights, facets, mappings, eventual consistency, and the managed OSIS lifecycle.
- **["Combine live and analytical data"](https://dynostudio.dev/docs/dynostudio-hybrid-queries/)** — Explicit DynamoDB, S3 Tables and OpenSearch planes; bounded UNION ALL and joins; watermark-split hybrid tables and recombined aggregates.
- **["Answer across two tables"](https://dynostudio.dev/docs/dynostudio-partiql-joins/)** — Key-aware joins, IN (SELECT …) semi-joins and anti-joins, and UNION / INTERSECT / EXCEPT — reads DynamoDB can't run alone.
- **["How many? Top ten?"](https://dynostudio.dev/docs/dynostudio-partiql-aggregates/)** — COUNT, SUM, AVG, MIN, MAX with GROUP BY and HAVING — plus PROFILE TABLE to discover an unknown table's shape.
- **["Change data — safely"](https://dynostudio.dev/docs/dynostudio-partiql-writes/)** — INSERT, UPDATE, DELETE and ON CONFLICT upserts, preview-first bulk sweeps, all-or-nothing transactions, and fail-fast `THEN` workflows with verification reads.
- **["Stand up or protect a data plane"](https://dynostudio.dev/docs/dynostudio-partiql-ddl/)** — Control-plane DDL: tables, GSIs, vector indexes, managed backups, S3 Tables replicas, OpenSearch projections, and guarded drops.

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](https://dynostudio.dev/docs/dynostudio-partiql-keywords/) is the flat index, and each core statement has a **dedicated page** ([SELECT](https://dynostudio.dev/docs/dynostudio-select/), [transactions](https://dynostudio.dev/docs/dynostudio-transactions/), [vector indexes](https://dynostudio.dev/docs/dynostudio-vector-index/), [backup and restore](https://dynostudio.dev/docs/dynostudio-backup-restore/), [OpenSearch](https://dynostudio.dev/docs/dynostudio-opensearch-index/), [hybrid queries](https://dynostudio.dev/docs/dynostudio-hybrid-queries/)) with quotable deep links.

> **Or browse the Query Library — no memorising:** You don't have to keep any of this in your head. Inside the editor, the **Query Library** is a searchable catalogue of the queries in this series, grouped by what you're trying to do. Pick one and it drops into the editor against the table you're viewing, classified in the "Executes as" strip just like anything you type. On **Professional**, read snippets insert with fillable `{parameters}` — a reusable question you fill and re-run; the free tier inserts the same query with a literal example value.

## 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.

**AWS references behind this dialect**

- [PartiQL for DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/ql-reference.html) — AWS docs: the native PartiQL surface that DynoStudio builds from.
- [Querying tables in DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Query.html) — AWS docs: why key-based reads are the baseline for predictable DynamoDB access.
- [Scanning tables in DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Scan.html) — AWS docs: why Scan warnings matter before a statement reaches production data.

> **The disclosure rule:** Every lowering is visible: the "Executes as" strip shows the native request(s), the editor squiggles what won't run or will bill heavily, and run status lines report items and pages actually read. If the UI didn't explain it, DynoStudio didn't do it.

---
_Source: https://dynostudio.dev/docs/dynostudio-partiql/ · DynoStudio Docs_