PartiQL & SQL

You paste SQL habits into PartiQL, run SELECT * FROM orders WHERE status = 'OPEN', and DynamoDB maps it to a table Scan that bills every item. PartiQL borrows SQL syntax; it does not borrow a relational planner.

PartiQL supports SELECT, INSERT, UPDATE, and DELETE against one table at a time on the server. There is no JOIN, no GROUP BY, no cross-item SUM. DynoTable's SQL Workbench fills that gap client-side: it fetches bounded result sets through normal Query/Scan APIs and runs relational operators on your machine, within DynamoDB's access-pattern rules.

What you can do after

Predict whether a PartiQL statement becomes a Query or a full-table Scan.
Write PartiQL DML knowing it executes directly against the table (not staged by default).
Run JOIN, GROUP BY, and aggregates in the Workbench when PartiQL cannot.
Explain to teammates why "SQL on DynamoDB" always means bounded, pattern-shaped reads.

Reading order

PartiQL vs SQL — syntax overlap vs engine limits; calibrate expectations before you write queries.
PartiQL examples — SELECT/INSERT/UPDATE/DELETE patterns that map cleanly to DynamoDB APIs.
SQL for DynamoDB — when client-side SQL helps and how DynoTable positions the Workbench.
JOIN — adjacency in keys vs client-side joins over fetched rows.
GROUP BY — aggregate in application code or Workbench after a selective read.
COUNT, SUM, aggregates — why COUNT(*) on PartiQL is still a Scan unless keys narrow the read.

0 of 7 readQuiz

DynamoDB PartiQL vs SQL: What Breaks

DynamoDB PartiQL looks like SQL but has no JOIN, GROUP BY, subqueries or aggregates. Every statement maps to one native operation. Here is what breaks.

Beginner8 min read

PartiQL for DynamoDB by Example

PartiQL for DynamoDB by example — SELECT, INSERT, UPDATE, DELETE with SQL-like syntax, plus the gotchas around partition keys and full-table scans.

Beginner5 min read

SQL for DynamoDB and the Limits of PartiQL

Can you query DynamoDB with SQL? PartiQL handles SELECT, INSERT, UPDATE and DELETE by key, but not JOIN, GROUP BY or COUNT(*). Here is what works.

Beginner8 min read

DynamoDB JOIN: How to Join Tables

DynamoDB has no JOIN and PartiQL doesn't add one. Why, the four workarounds devs use, and how DynoTable's SQL Workbench runs a real JOIN.

Intermediate10 min read

DynamoDB GROUP BY: How to Aggregate Instead

DynamoDB and PartiQL have no GROUP BY, COUNT or SUM. The patterns that replace it — atomic counters, Streams + Lambda rollups, and app-side grouping.

Intermediate9 min read

How to COUNT, SUM and Aggregate in DynamoDB

How to COUNT, SUM and aggregate in DynamoDB — what Select=COUNT costs, why there is no native SUM or AVG, and the patterns that give you real totals.

Beginner8 min read

Knowledge checkTake the quiz

Check what you’ve learned in this section.

SELECT count(*) FROM events without a key condition reads the whole table and charges read capacity for every item evaluated, even though the response is one number. A Workbench JOIN between orders and customers only joins rows you already paid to fetch — widen the underlying Query and the join cost grows with item size and row count.

PartiQL parameter binding and partiql-supported functions mirror DynamoDB limits: no subqueries, no cross-table references in one statement, no server-side aggregation across partitions. That is why the Workbench exists — SQL familiarity without pretending the server gained a planner. Position every Workbench query as "SQL within DynamoDB's access-pattern rules": bounded reads first, relational operators second.

Try it in DynoTable

Download DynoTable. The SQL Workbench editor is available on free read-only plans with autocomplete powered by a local inferred schema. Paid plans unlock running Workbench queries and exports.

PartiQL SELECT is free to run; PartiQL DML (INSERT, UPDATE, DELETE) executes directly with a warning — it bypasses write staging. Use staging in the item editor when you want a reviewable diff before commit.

The query cost status bar on Workbench and PartiQL tabs shows ~N items · ~R RCU when the plan is known, so a PartiQL statement that degenerates to Scan is visible before you run it. On a 500k-item table, a keyless PartiQL SELECT that becomes a Scan can burn on the order of 125k RRUs for an eventually consistent full read of ~2 KB items — versus a handful of RRUs for a keyed Query. Size that tradeoff in the pricing calculator before you paste production PartiQL into a job. Read the SQL Workbench docs for JOIN and aggregate limits, and use the query builder when you want the same access pattern without hand-writing API JSON.