DEV Community: DynoTable

DynamoDB Limits and Quotas, Verified on the Live Service

DynoTable — Thu, 24 Sep 2026 14:13:01 +0000

What are the DynamoDB limits?

An item is capped at 400 KB, a partition key at 2,048 bytes and a sort key at 1,024
bytes. A batch write takes 25 items, a batch get 100 keys, a transaction 100 actions.
A table gets 20 global and 5 local secondary indexes. Every one of those numbers on
this page was established by sending the request to Amazon DynamoDB and reading what
came back.

How these numbers were established

AWS publishes its quotas without evidence, and that is normally fine — until a number
is load-bearing for a design decision and you want to know whether it means 400,000
bytes or 409,600, whether it counts your attribute names, and what exactly the service
says when you cross it.

So we probed them. For every limit in the first table below, a request was built to sit
exactly on the documented value and sent to the live service in us-east-1; then a
second request, one unit past it. The first must be accepted and the second rejected —
that pair is what locates the edge, rather than taking the documentation's word for it.
The rejection message in the last column is the service's own sentence, captured
verbatim and never retyped.

Note

The probes are a script in this site's repository, and the
captured output is committed as generated JSON. The tables below are built from that
JSON, so an error message cannot drift out of sync with what the engine actually says —
a test fails the build if it does.

Four rows could only be established from the rejection side. Those are CreateTable
limits whose accept side would mean building a table with twenty indexes and waiting for
each to become active, for a number the rejection states outright. The How it was
established column says which is which; it is not decoration.

Verified limits

Limit	Value	How it was established	What the service returns when you cross it
Maximum item size	409,600 bytes	Accepted at 409,600, rejected at 409,601	`ValidationException: Item size has exceeded the maximum allowed size`
Maximum partition key value	2,048 bytes	Accepted at 2,048, rejected at 2,049	`ValidationException: One or more parameter values were invalid: Size of hashkey has exceeded the maximum size limit of2048 bytes`
Maximum sort key value	1,024 bytes	Accepted at 1,024, rejected at 1,025	`ValidationException: One or more parameter values were invalid: Aggregated size of all range keys has exceeded the size limit of 1024 bytes`
Maximum nesting depth	32 levels	Accepted at 32, rejected at 33	`ValidationException: 1 validation error detected: Nesting Levels have exceeded supported limits: Attributes in the item have nested levels beyond supported limit`
Maximum expression length	4,096 bytes	Accepted at 4,096, rejected at 4,097	`ValidationException: 1 validation error detected: Invalid ConditionExpression: Expression size has exceeded the maximum allowed size;`
Maximum items per BatchWriteItem	25 items	Accepted at 25, rejected at 26	`ValidationException: 1 validation error detected: Value '<your request>' at 'requestItems' failed to satisfy constraint: Map value must satisfy constraint: [Member must have length less than or equal to 25, Member must have length greater than or equal to 1]`
Maximum keys per BatchGetItem	100 items	Accepted at 100, rejected at 101	`ValidationException: 1 validation error detected: Value at 'RequestItems.<table-name>.member.Keys' failed to satisfy constraint: Member must have length less than or equal to 100`
Maximum actions per TransactWriteItems	100 items	Accepted at 100, rejected at 101	`ValidationException: 1 validation error detected: Value '<your request>' at 'transactItems' failed to satisfy constraint: Member must have length less than or equal to 100`
Global secondary indexes per table	20	Rejection only	`ValidationException: One or more parameter values were invalid: GlobalSecondaryIndex count exceeds the per-table limit of 20`
Local secondary indexes per table	5	Rejection only	`ValidationException: One or more parameter values were invalid: Number of LocalSecondaryIndexes exceeds per-table limit of 5`
Projected non-key attributes per index	20	Rejection only	`ValidationException: 1 validation error detected: Value '<your request>' at 'globalSecondaryIndexes.1.member.projection.nonKeyAttributes' failed to satisfy constraint: Member must have length less than or equal to 20`
Projected non-key attributes per table	100	Rejection only	`ValidationException: One or more parameter values were invalid: Number of projected attributes in all indexes exceeds limit of 100, number of projected attributes:120`

Environment: Amazon DynamoDB, live service, us-east-1, probed 2026-08-27 with the AWS
SDK for JavaScript v3.

What the probes turned up

400 KB means 409,600 bytes, and it counts your attribute names. An item measured at
exactly 409,600 bytes was accepted; 409,601 was rejected. The measurement counts the
UTF-8 length of every attribute name plus every value, which is the same accounting our
item size calculator implements — the probe
builds its payload with that library, so the two agree by construction rather than by
assertion. The deeper modelling problem behind this limit has its own guide:
the DynamoDB item size limit.

The projected-attributes limit everyone quotes is the wrong one. The AWS
Quotas page
documents one figure — "up to 100 attributes combined for all of a table's local and
global secondary indexes" — and never mentions a per-index cap. There is one, and it is
20. A CreateTable projecting 21 non-key attributes into a single index is rejected
before the per-table total is anywhere near 100. The 20 is documented, but only in the
API Reference's
Projection
page, as an array-member constraint: "Maximum number of 20 items". If you plan an index
against the Quotas page alone, the API will refuse a schema the Quotas page says is
fine. Both numbers are in the table above, each with the rejection that proves it.

Two of the messages contain AWS's own typos, reproduced here rather than silently
corrected — maximum size limit of2048 bytes is missing a space, and
number of projected attributes:120 is missing another. If you are grepping logs for
these strings, grep for what the service sends, not for what reads correctly.

Sort keys are measured in aggregate. The sort-key rejection says "Aggregated size of
all range keys", not "the sort key", because the same 1,024-byte budget covers the sort
key of the table and of every local secondary index the item lands in.

The 1 MB page, which raises nothing at all

Every limit above announces itself by rejecting you. The Query and Scan page limit does
not. Cross it and DynamoDB returns a short page and a LastEvaluatedKey, with no error
and no warning — which is why "my Scan only returned part of the table" is such a common
surprise, and why
pagination is not optional.

That also means there is no error message to quote, so it was measured instead of
provoked:

At 1,000 bytes an item, a page held 1,029 items and returned a LastEvaluatedKey — 1,029,000 bytes of item data, with the 1,030th item left for the next request. At 5,000 bytes an item, a page held 208 items and returned a LastEvaluatedKey — 1,040,000 bytes of item data, with the 209th item left for the next request.

Neither page held 1 MiB of item data — the first fell about 19,576 bytes short. So the page budget charges more per item than the item's own bytes.

Two probes at different item sizes are enough to pin that down. Treating a page as items × (item bytes + per-item overhead) ≤ budget, only 7 whole-byte overheads are consistent with both measurements, and exactly one of them puts the budget on a round binary megabyte: an overhead of 19 bytes an item, with the budget between 1,048,551 and 1,048,971 bytes — a range containing 1,048,576. DynamoDB's "1 MB" is binary, as its own quotas page states, and it is spent on item bytes plus per-item overhead. Budget for roughly 19 bytes of it per item.

Quotas we did not probe

The limits below are cited to AWS, not measured. They are account-level quotas: most
are adjustable on request, and reaching them means provisioning throughput that bills by
the hour, creating thousands of tables, or committing to a year of reserved capacity.
None of that is a probe, so none of it is presented as one. The source for every row is
the AWS
Quotas in Amazon DynamoDB
page.

Quota	Default value	Adjustable	Why we did not probe it
Tables per account per Region	2,500	Yes	Creating 2,500 tables to watch the 2,501st fail leaves an account someone has to unwind.
Provisioned throughput per table	40,000 RCU and 40,000 WCU	Yes	Provisioning 40,000 units bills by the hour whether or not a single request is made.
Provisioned throughput per account	80,000 RCU and 80,000 WCU	Yes	Same reason, twice over — and it changes an account-wide setting.
On-demand throughput per table	40,000 RRU and 40,000 WRU	Yes	Reaching it means sustaining 40,000 requests a second, which is a load test with a bill.
Active reserved capacity per account	1,000,000 capacity units	Yes	Reserved capacity is a one-year purchase commitment, not a probe.
Table size	No practical limit	—	AWS states tables are unconstrained in items and bytes; there is no edge to find.

Warning

Because these are adjustable, your account's values may differ from the defaults. Check
the Service Quotas console for what your account is actually set to before designing
around any of them.

Throughput and partition limits

The quotas above are account bookkeeping; these three are architecture, and they are
the limits that actually throttle production tables. All are cited to AWS, not
probed — a throughput edge cannot be probed politely, because finding it means
sustaining the load that crosses it.

3,000 RCU and 1,000 WCU per second, per partition. However much capacity the table has, the slice any single partition can serve is capped — and a single partition key value lives in exactly one partition. A key hot enough to cross either number throttles even while the rest of the table sits idle, and adding table capacity does not raise it. This is the hot partition problem.
10 GB per item collection — only on tables with a local secondary index. An item collection is every item sharing one partition key value, base table plus LSI entries. With an LSI the collection is capped at 10 GB and further writes are rejected with ItemCollectionSizeLimitExceededException; without one, a partition key value's storage is unbounded and simply splits across partitions.
On-demand ramps to double the previous peak. A new on-demand table serves up to 4,000 writes and 12,000 reads per second immediately. Beyond that it scales to twice whatever it has already sustained — but a spike past double the previous peak within 30 minutes can be throttled while DynamoDB splits partitions. Load that doubles gradually never notices; load that jumps tenfold in a minute does.

Sources: the AWS
partitions and data distribution
page for the per-partition figures, the
LSI developer-guide page
for the item-collection cap, and the
on-demand mode page
for the ramp behavior.

Which limits you should design around

Most of these you will never meet. The handful that shape real designs:

400 KB per item is a modelling constraint, not a quota. An item that approaches it is usually an unbounded one-to-many relationship stored as an embedded list. See the item size limit.
The 1 MB page governs every Query and Scan you write. Code that ignores LastEvaluatedKey is quietly wrong the day your data outgrows one page.
25 items per batch write and 100 per batch get shape your bulk-load loops. See batch operations.
100 actions per transaction is the one people hit while trying to make DynamoDB behave relationally. See transactions.
20 GSIs, 5 LSIs, 100 projected attributes constrain access-pattern design far more often than the throughput quotas do, and the LSI count is fixed the moment the table is created. See index projections and GSI vs LSI.

Every rejection quoted above was captured from the request that produces it; the four
CreateTable rejections were captured specifically for this page.

To check a single item against the 400 KB line without writing it,
the item size calculator runs in your browser.
To look at the items in your own tables, DynoTable is a desktop DynamoDB
client.

FAQ

What is the DynamoDB item size limit?
400 KB per item — 409,600 bytes exactly, verified by probe, counting the UTF-8 bytes
of every attribute name and value. An item that approaches it is usually an unbounded
relationship stored as an embedded list.

How much throughput can a single DynamoDB partition handle?
3,000 read capacity units and 1,000 write capacity units per second. The cap is per
partition, and one partition key value never spans partitions, so a hot key throttles
at those numbers no matter how much capacity the table has.

What is the 10 GB limit in DynamoDB?
It is the item-collection cap, and it exists only on tables with a local secondary
index: all items sharing one partition key value, across the base table and its LSIs,
must fit in 10 GB. Tables without an LSI have no such cap.

Is there a limit on DynamoDB table size?
No practical one — AWS places no ceiling on a table's item count or total bytes. The
limits that bind are per item (400 KB), per page (1 MB), and per partition (3,000 RCU
and 1,000 WCU).

How many actions fit in one DynamoDB transaction? 100. A TransactWriteItems with 100 actions is accepted and one with 101 is
rejected — both verified against the live service, with the rejection quoted in the
table above.

How many writes per second before a new DynamoDB table throttles?

DynoTable — Fri, 28 Aug 2026 07:45:04 +0000

AWS documents that a brand-new On-demand capacity table serves "up to 4,000 write request units per second" out of the box. The study everyone still cites for what actually happens — the one Capital One and ScyllaDB both link — measured it in 2019, before warm throughput, before configurable maximums, before the current scaling rules existed. As far as we can tell, nobody has published a measurement since.

So we ran one. On 2026-08-27, against a table created minutes earlier in us-east-1, offered write load ramped from 1,000 to 8,000 requests per second:

Offered	Achieved	Throttled requests
1,000/s	1,000/s	0
2,000/s	2,000/s	0
3,000/s	3,000/s	0
4,000/s	4,000/s	0
5,000/s	4,132/s	25,992
6,000/s	4,131/s	55,966
8,000/s	4,134/s	115,922

The documented baseline holds, and it is slightly conservative: the service accepted everything up to 4,000/s without a single rejection, then pinned at 4,130 ±2 writes per second no matter how hard we pushed. Three windows, three offered rates, the same ceiling to within 0.05%. Reads never throttled at all — we drove a seeded table past 12,700 eventually-consistent reads per second and the shortfall above that was our own client, not DynamoDB.

One table, one day, one region, ~1 KB items with uniformly random keys — no Hot partition in sight. That scope is the honest print on every number here. The rest of this post is how we measured it, including the part where the benchmark failed three times before it worked, and none of the failures were DynamoDB's fault.

The throttle is a 400, and it names the wrong suspect first

When the ceiling hits, the error you get is worth reading closely:

ThrottlingException: Throughput exceeds the current capacity of your table or index.
DynamoDB is automatically scaling your table or index so please try again shortly.
If exceptions persist, check if you have a hot key:
https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-partition-key-design.html

Three observations, all measured:

It is an HTTP 400, not a 5xx. Your retry policy and your dashboards need to know that. A client that only retries 5xx will drop these on the floor; a monitor that only alarms on 5xx will show a green service while a third of your writes bounce.
The first throttle arrived 0.9–3.8 seconds into each over-baseline window — the service gives you a short grace burst before the ceiling engages, and the higher the offered rate, the sooner it bites.
The hot-key hint is a default, not a diagnosis. Our keys were uniformly random UUIDs; there was no hot key. At small scale, the first suspect for this message is simply the table-level ceiling.

Latency stayed indifferent to all of it: p50 write latency was 4–5 ms in-region in every window, throttled or not. Rejection is cheap for the service — it does not slow down, it just says no.

You cannot measure this from a laptop

Our first instrument was the obvious one: a Node script on a laptop in Madrid. It paced 1,000 writes per second cleanly and collapsed at 2,000 — not because DynamoDB pushed back, but because ~100 ms of Atlantic round-trip means 2,000 in-flight requests per second needs hundreds of concurrent sockets, and the event loop drowned. The service never throttled once. We were benchmarking our own Wi-Fi.

Attempt two moved the runner into the same region as a single Lambda function. In-region round-trip is ~5 ms, and one 3 GB function paced 2,000 requests per second cleanly at 10 ms p50. Past that it flatlined around 1,100/s with the CPU pinned: request signing and response handling are single-threaded JavaScript, and one runner simply cannot sign 4,000 requests a second. Memory allocated: 3 GB. Memory used: 253 MB. The bottleneck was never RAM — a Lambda's CPU share scales with its memory setting, and we were buying compute, not storage.

So the final instrument is a fleet of eight Lambdas, each pacing one-eighth of the total offered rate, all started against a shared wall-clock T0 so their windows line up. Eight runners at a comfortable 1,000/s each gave us 8,000/s of offered load with headroom, and the aggregate is a sum of counted requests — no extrapolation anywhere.

Three runs died before one worked, and DynamoDB was innocent every time

The fleet's first run ended with a runner reporting it had started 882 seconds after T0 — fifteen minutes late to a twenty-second appointment. The second run died with a read timeout. The third, with retries disabled, failed loudly on all eight runners at once. Meanwhile CloudWatch showed every single Lambda finishing its four-minute measurement cleanly, on time, no errors.

The culprit was the connection between the laptop and Lambda. A synchronous invocation holds one HTTPS connection open, fully silent, for the entire run — and a residential router quietly kills silent connections after a few minutes. The CLI, seeing a dead socket, did the worst possible thing: it silently retried, re-running a measurement Lambda that then found its T0 long gone. A benchmark harness that can invisibly run twice is not a harness; it is a random number generator with an AWS bill.

The shape that finally worked has three rules we would now use for any long-running remote measurement:

Fire-and-forget, results out-of-band. Runners are invoked asynchronously (the connection closes in milliseconds) and write their results as items into a small DynamoDB table; the driver polls for eight result rows. No connection lives longer than a request.
Retries are off everywhere. The measurement client runs at one attempt per request — a retry would silently absorb the throttles we exist to count — and the invocation path has retries disabled too, so no runner can ever execute twice.
A watchdog instead of a hang. Each runner races its schedule against a deadline; if anything wedges, it returns partial counts plus a snapshot of exactly where it was stuck, rather than timing out in silence. A failed run that explains itself costs one read; a hung one costs an evening.

Every request also carries an 8-second timeout. The run that hung did so because a single in-flight request with no timeout wedged the final drain step forever. One unbounded wait, per ~4 million requests, was enough.

What the reads did

The read phase ran against a second fresh table seeded with 1,000 items, using Eventually consistent read GetItems (~1 KB each, 0.5 read units):

Offered	Achieved	Throttled
4,000/s	4,000/s	0
8,000/s	7,941/s	0
12,000/s	11,119/s	0
16,000/s	12,762/s	0

Zero throttles, ever. The documented 12,000 read/s baseline holds and we could not find its edge: at 16,000/s offered, five of our eight runners hit their own client-side saturation, so the 12,762/s figure is where our fleet topped out, not where DynamoDB did. We are saying that plainly rather than dressing it up as a service limit. Reads in-region ran at 2–4 ms p50.

Two smaller numbers worth keeping: a fresh on-demand table went from CreateTable to ACTIVE in 22 seconds on the benchmark run and 7.4 seconds on an earlier probe — budget for the variance, not the best case. And the entire benchmark, 672,116 billed writes and 1.08 million reads, cost $0.97. The instrument is reusable; the experiment is a coffee.

Half an hour of pressure does not double the ceiling

AWS's growth rule says on-demand capacity accommodates up to double your previous
peak. We wanted to see that happen, so after the ceiling run we held a table at
8,000 writes/s of offered load for 34 contiguous minutes and bucketed the
achieved rate per 10 seconds. The shape:

Minutes under load	Ceiling
0–8	~4,000/s (baseline, unmoved)
9–25	~5,000/s
26	~6,000/s
27–34	~7,000/s

Growth arrives in abrupt ~1,000/s steps, not a ramp — a minute is flat at one
rate, the next minute is flat at the next. The first ceiling is sticky for a
full 8 minutes of continuous over-demand. And after 34 minutes the table served
7,000/s: 1.75× where it started, still short of the offered 8,000 and of a clean
doubling. If your launch needs more than ~4,000 writes/s on a new table, warm it
up ahead of time or set its maximum on-demand throughput explicitly — the growth
mechanism is real but it is neither instant nor generous on your schedule. The behavior is stable, too: under 9,000/s of offered load, the 2019 study’s table had grown to about 7,000/s when the test ended — the same plateau ours reached seven years later. That
run cost $12.67, the most expensive thing we did all day.

What transfers if you measure a cloud service yourself

Put the load generator in the same region as the target. Otherwise you are measuring your route, not the service.
One Node process tops out around 2,000 signed requests per second regardless of memory; shard the load across runners and sum counted results.
Disable retries on the measurement path, at every layer. Retries exist to hide exactly what a benchmark exists to see.
Never hold a silent connection across a long run. Invoke async, deliver results out-of-band, poll.
Give every request a timeout and every runner a watchdog that returns partial data with a stuck-state snapshot.
Set a hard operation ceiling per runner so a pacing bug aborts instead of running up the bill, and tear down everything the run created — tables, roles, functions, logs — in a finally.

The reference pages this feeds

The full dataset — every window, every runner, per-latency percentiles, the verbatim error strings — now backs the measured tables in our DynamoDB limits reference, alongside the item-size and page-limit probes we published earlier. If you work against DynamoDB daily, DynoTable is our desktop client for it — the same team, the same habit of checking claims against the live service before repeating them.

Why we hand-wrote a PartiQL parser for DynamoDB

DynoTable — Sat, 15 Aug 2026 16:22:30 +0000

DynamoDB accepts a narrow slice of PartiQL and rejects everything else at request time. GROUP BY? ValidationException. A statement-level LIMIT? ValidationException. The * operator, CAST, a subquery? All of them parse fine in your head, travel over the wire, and die on the server. The only place that knowledge lived was the AWS documentation and the error messages, which meant every editor for DynamoDB — including ours, for a while — would happily let you compose a statement the engine was guaranteed to refuse.

We wanted the refusal to happen in the editor, on the keystroke, with a red squiggle on the exact clause and a one-click fix where a rewrite exists. That editor need turned into a hand-written lexer and CST parser for DynamoDB's PartiQL dialect, and this week we open-sourced it: dynamodb-partiql-parser, pure TypeScript, zero dependencies, MIT, with the CodeMirror wiring published separately as codemirror-lang-partiql. This post is why it's hand-written, what the first linter got wrong, and the two bugs that only showed up when someone pasted garbage.

Regex was fine, until it wasn't

The first PartiQL linter in DynoTable was about 650 lines of regex and token scanning, and it was genuinely useful: nineteen distinct checks, quick fixes for the common traps (IN (...) to [...], LIKE to contains(), IS NULL to attribute_not_exists()). It shipped, it caught real mistakes, users stopped filing "why does my query fail" tickets for the cases it covered.

But a regex linter knows patterns, not structure. It couldn't see that * in SELECT price * quantity is arithmetic DynamoDB rejects, because * also means "all columns" and telling those apart requires actually parsing. Its diagnostic ranges were approximations — close enough to point at a line, too coarse to drive a quick fix that splices text at exact offsets. And every new check made the pile more fragile, because each regex had to defend against every other regex's assumptions.

The fix for "the linter needs structure" is a parser. The question was which one.

Nobody had built one

For the Workbench's real-SQL side we had already been through this: an off-the-shelf SQL parser that lied to us, replaced by sql-parser-cst, which carries a source range on every node and preserves quoted-versus-unquoted identifiers. That experience set the bar for what the PartiQL side needed — a lossless concrete syntax tree, not a lossy AST.

But PartiQL is not SQL where it counts for a parser. DynamoDB's dialect writes IN lists with brackets (WHERE OrderID IN [100, 300, 234]), has bag literals (<<'a', 'b'>>), map literals with quoted keys ({'rating': 5}), a MISSING literal, document paths with list indexes (Devices.FireStick.DateWatched[0]), and RETURNING ALL OLD * — none of which a SQL grammar knows. In the other direction it lacks half of what a SQL grammar insists on. At the time, the parsers on npm were WebAssembly builds of AWS's Rust implementation for generic PartiQL, with no notion of what DynamoDB specifically rejects.

So we wrote one: a small lexer and a recursive-descent parser, modeled on the shape sql-parser-cst taught us to want. Every node carries its byte range. The whole thing has zero runtime dependencies — a property the CI now asserts, because it's what makes the parser embeddable anywhere, including the browser, including your project.

The grammar was the easy half. A linter's parser spends its whole life parsing broken code. Mid-keystroke, half a statement, a typo in the third clause. Stopping at the first error would make the editor useless, so the parser is error-tolerant: it records a diagnostic, resynchronizes, and keeps going, so the fourth clause still lints while the second is incomplete.

Swapping the engine without breaking the plane

By the time the parser was ready, the regex linter's four functions were load-bearing across the editor — including the one that decides whether a statement is safe to auto-execute. Silently changing that behavior shows up as "the editor won't run my query," which is the kind of bug users don't report so much as leave over.

So the swap was a strangler: the old linter was renamed, frozen, and kept in the tree. The new parser-driven linter re-exported the exact same four functions. And a parity corpus ran every fixture through both linters and pinned the outputs against each other — every diagnostic the regex version produced, the parser version had to produce too, before it was allowed to produce more. The old linter is still there today, frozen, as executable documentation of what the swap promised.

The bugs that only garbage finds

Two failures never appeared in any real query and both would have taken the editor down.

A CodeMirror linter runs synchronously on the document, on every change, with no error sink above it. One uncaught exception doesn't fail a lint — it white-screens the editor. And a recursive-descent parser has a natural uncaught exception built in: the call stack. Paste [[[[[[… a few thousand brackets deep, or a NOT NOT NOT … chain, and each nesting level is a stack frame; V8 eventually throws RangeError: Maximum call stack size exceeded straight through the linter.

The fixes are boring on purpose. Expression recursion has a hard depth ceiling — five hundred levels, far beyond anything a human writes, well under the stack budget — past which the parser emits a single diagnostic instead of throwing. And the constructs where pastes realistically chain, like A UNION B UNION C … thousands of arms long, were rewritten from recursion into flat lists: one parseSelect frame and an array of set-operations, instead of one frame per arm. The stress suite now pastes 100 KB of garbage and 30,000-deep operator chains at every build, and the public package wraps the whole pipeline in a lint() entry point that never throws, because the next editor to embed this will have the same no-error-sink problem we did.

A test suite you can audit against AWS's docs

The dialect rules — what DynamoDB accepts, what it rejects, which rewrite fixes what — all come from AWS's PartiQL reference. Documentation-derived behavior has a specific failure mode: the doc moves, the code doesn't, and nobody notices.

So the corpus is structured against it. Two hundred and eight fixtures, and every one opens with the URL of the AWS documentation page the rule comes from. A coverage table maps each documented rule to its fixture, and the suite fails if a rule loses its fixture. When AWS changes the dialect, the diff is a fixture diff with a citation on it.

That discipline paid for itself the week we open-sourced. The linter's IN-list warning cited two caps: 50 values on a partition key column, 100 on a non-key column. Re-verifying every number before publication, we could confirm the 100 in AWS's current documentation — and could not find the 50 anywhere in an operative doc. It survives all over blog posts and old forum answers, but the primary source has moved on. The linter had it right by accident (it only warns past 100, since without your schema it can't tell which case applies), and the comment now says exactly which half of the claim is documented and which is folklore.

What transfers if you're building one

A hand-written recursive-descent parser for a small dialect is days of work, not months, and you own every error message. The scary version of "write a parser" assumes a big grammar.
Build a CST, not an AST. Byte ranges on every node are what turn diagnostics into quick fixes; a lossy tree can't splice text.
If the parser feeds a linter, error tolerance is the feature. Recover and continue; a parser that stops at the first error lints nothing after it.
Swap engines behind a frozen interface with a parity corpus pinning old against new. The old implementation is the spec you already agreed to.
Anywhere input can nest, someone will paste something that nests absurdly. Depth-cap the recursion and flatten the chains; test with garbage, not just queries.
Cite your sources in the tests. A fixture that names the doc page it encodes is a test that can be audited when the doc changes — and it will change.

The parser is on GitHub and npm (npm install dynamodb-partiql-parser), with the editor integration in codemirror-lang-partiql. If you want the dialect itself rather than the parser, PartiQL vs SQL covers what DynamoDB's subset can and can't do and PartiQL examples is the practical walkthrough; the editor all of this was built for is in DynoTable, and you can try it free.

Your agent doesn't need every tool in its context

DynoTable — Sat, 08 Aug 2026 07:54:20 +0000

DynoTable's AI agent can reach 38 tools. It rarely
sees all of them at once. Where we drew the line between what the model gets
immediately and what it has to go looking for turned out to be the most
consequential decision in the whole toolkit, and the line ended up nowhere
near where we first put it.

We built a discovery mechanism so the model would start with a small set and
search for the rest. Then we watched cheap models use it, and moved 27 of
the 38 tools back into the always-visible core. The mechanism survived. Our
theory about who needed it did not.

We learned this building a tool surface for models that can't be
trusted to go looking.

A tool the model never calls still costs you

Every tool you expose is its name, its description, and its full input schema,
serialized into the request before the user has typed anything. Thirty-eight of
those is not free.

Tokens are the smaller half of the bill. The real cost is selection accuracy:
the more near-identical options a model scans, the more often it picks the
wrong one. Our catalog is full of near-identical options on purpose. Five
of our tools exist twice, openTable and proposeOpenTable, openWorkbench
and proposeOpenWorkbench, and so on. Each pair does the same thing; one does
it immediately, the other emits a chip the user clicks first. That distinction
is load-bearing for agent safety and nearly invisible in a flat
list of names.

The Model Context Protocol's own client guidance leads with this exact
point: loading every tool definition up front wastes tokens, adds latency, and
degrades the model's performance. Agreeing with that is easy. Deciding which
tools lose their seat is where it gets interesting.

We built a search tool. The floor model wouldn't call it.

The mechanism is two-tier. A set of tools is active from the first step. The
rest are invisible until the model calls searchTools(query), which scores the
catalog on names, descriptions and keywords, returns the matches, and adds them
to the set of tools the model is allowed to call on subsequent steps.

Diagram: view on dynotable.com

Then we ran it against our floor model. We don't tune this agent against a
frontier model, it runs on
your own Bedrock credentials, so people pick
cheap models, and we optimize for the cheapest one. Asked about an attached
file, that model went hunting through the open-tabs listing instead. It
rarely called the search tool at all.
Anything not directly visible did not exist to it.

That result kills the obvious design. If discovery is the only route to a tool,
every request that needs that tool depends on the model choosing to go looking, and the models most likely to need help are the least likely to ask for it.

So the split stopped being "small core, big tail" and became a question about
the request, not the tool: does the user's phrasing name the tool? The 11
tools we kept discoverable are the ones where the answer is yes. "Export this
to CSV" makes a model search for export. "Show me last month's orders" does
not make it search for a filter-setting tool, so that one stays inline. Index
statistics, saved specs, relationship introspection, and the staged-change
surfaces are all things a user asks for by name when they want them, and never
implicitly.

Twenty-seven inline is not a number we would have defended in advance. It's the
number that survived contact with the model we actually ship against.

The race that would have made discovery silently useless

Discovery has a timing constraint that is easy to get wrong and hard to notice.

When the search tool returns matches, those names have to join the allowed set
before the model's next step is prepared. The obvious place to do that is the
hook that fires when a step completes. That hook is documented to fire, in some
SDK versions, after the next step's preparation, which means the mutation
lands one step too late.

The failure mode is nasty. The model searches. It gets a correct result naming
the tool it needs. It calls that tool on the very next step and is told the tool
doesn't exist. Intermittent, dependent on which SDK version you resolved, and it
reads like a stupid model rather than a broken runner.

The fix is to mutate the allowed set inside the search tool's own execution,
which is guaranteed to complete before the loop advances. That is a one-line
difference in where a statement lives, and it is the difference between a
working discovery mechanism and one that fails a fraction of the time for
reasons no one will attribute correctly.

Three searches, then stop

Search is capped at 3 calls per agent turn. The fourth returns this instead
of running:

{"error": "search-budget-exhausted", "budgetCap": 3}

The cap exists because of a specific loop. The model searches, doesn't find what
it imagined, searches again with a synonym, doesn't find that either, and burns
its entire step budget inside the search tool without ever touching the
database. Capping it forces a decision, commit to one of the tools already
found, or ask the user, at the point where more searching has stopped paying.

The error message when a model calls a tool it hasn't discovered follows the
same principle we use for
every validator in the agent:

Tool 'startExport' not in active set. Call searchTools(query='startExport')
to discover it, or use one of: <inline tool names>

A rejection that names the recovery action costs one extra step. A rejection
that just says no costs the turn.

One row per tool, everything else derived

Each tool is declared once, in a single flat list, and the row carries the
tool's entire identity: its name and description, the keywords search matches
on, whether it starts inline or discoverable, which tier it runs in, and how it
is exposed over MCP.

Those tiers matter as much as the visibility split. Twenty-one tools are
silent, reads that run without interrupting anyone. Sixteen are gated
behind the authorization ladder. Exactly one belongs to neither, because the
search tool isn't a capability the agent uses on your data; it's part of the
loop itself. MCP exposure is a third axis on the same row: read-only, staging,
full, or excluded outright, which three tools are.

The rule that keeps this honest is that every other list in the system is
derived from those rows, the silent-tier set, the MCP scope tiers, the
write-scoped set, and none of them is maintained by hand. A hand-kept silent
list next to a hand-kept MCP list is exactly how a tool ends up correctly gated
in chat and quietly ungated to an external client.

The constraint we didn't see coming is that the declaration list has to contain
zero runtime imports. It's shared by the desktop UI and the backend, and a
single import reaches, transitively, a Node-only crypto dependency by way of one
tool's implementation. Pull that into the browser bundle and the app fails at
module load. Neither the type checker nor the unit tests catch it, both resolve
the import happily. What catches it is a test that reads the file as text and
fails on any import statement at all, which feels crude right up to the first
time it saves you.

What transfers if you're building one

Count your tools before you defend your architecture. The right split is a measurement, not a principle.
Test discovery against your weakest model. A frontier model will search when it should; that tells you nothing about the model your users pick.
Decide visibility by whether the user's own phrasing names the tool. Tools invoked implicitly belong inline; tools people ask for by name can be found.
Check when your framework's step hooks actually fire before you put anything order-sensitive in one.
Cap the meta-tools. Anything that can be called repeatedly without touching real state will be, and a step budget spent searching is a turn wasted.
Make undiscovered-tool errors name the recovery call, the same as any other validator error.
Declare each tool once and derive every other list from it. Two hand-kept lists of the same tools disagree eventually, and the disagreement shows up at a security boundary.
If a module carries a load-bearing constraint your compiler can't express, write the crude test that enforces it as text.

Where this runs

All of this ships inside DynoTable's
tool catalog, schema-aware querying on your own
AWS Bedrock credentials, with writes that only ever land in a
reviewable staging area. The same declarations drive the
MCP server that external agents connect to, where
the exposure tier on each row becomes the scope an external client is granted;
how we made that safe (OAuth, consent,
credential isolation) is a separate story.

And the layer underneath all of it, the validators that make each of these tools
survivable by a cheap model, is
its own post.

GPT-6 Luna vs GPT-5.6 Luna vs other cheap models: benchmarked on real agent work

DynoTable — Thu, 06 Aug 2026 19:21:24 +0000

Updated September 23, 2026: added GPT-6 Luna, released on September 22, and autocomplete results. Two statements in the first version are no longer true and are corrected below: that GPT-5.6 cannot do autocomplete in DynoTable, and that Bedrock's Converse API cannot reach GPT-5.6.

On July 30, OpenAI cut GPT-5.6 Luna's price by 80%, and the same cut landed on Amazon Bedrock. Seven weeks later GPT-6 Luna arrived at about half of that new price. Every comparison page updated a pricing table. None of them answered the question that matters: at that price, is Luna actually good enough to drive an agent?

We had a way to answer it. DynoTable's AI agent runs real agent loops against DynamoDB (tool calls, PartiQL queries, SQL routing, staged writes) and every model we ship is gated by an Eval suite that scores those loops end to end. So we pointed the suite at both Lunas: 201 test cases, three runs each, against a live database, with every call priced from the tokens it actually used.

The verdict:

GPT-6 Luna scored 93.02%, GPT-5.6 Luna 93.94%, and Amazon Nova 2 Lite (the cheap model we ship as our tuning floor) 96.00%, on the same 201 cells with the same scorers.
GPT-6 Luna is the cheapest model we have measured: $0.00025 per call, 2.4× less than GPT-5.6 Luna and 12× less than Nova 2 Lite.
Both Lunas now do autocomplete. GPT-6 Luna scores 96.97% on it, second only to Claude Haiku 4.5.

A new generation that ties its predecessor on agent work and halves the bill. The numbers are below, plus the caching behavior the pricing tables miss and the transport quirks that cost us debugging time.

What this benchmark is (and is not)

These are not public benchmark scores. Our suite drives the production agent through real DynamoDB sessions: pick the right tool for a plain question, read an item by composite key, stage a write for human review, respect PartiQL's no-JOIN boundary, route a GROUP BY to the SQL surface instead, ask a clarifying question only when the request is genuinely ambiguous, refuse a "delete everything". A scorer asserts the outcome of each session, we learned the hard way what happens when a scorer asserts tool names instead.

Four honesty notes before any chart:

"Verified" in our model picker is a coverage claim, not a quality bar. It means the eval suite runs against that model. Both Lunas are verified and scored below our floor model, both facts are published here.
Nova 2 Lite and Claude Haiku 4.5 are the two models this app ships against, so months of prompt tuning have gone toward them specifically. Neither Luna got any tuning. Read the gap with that in mind.
GPT-6 Luna was measured seven weeks after the others. Same 201 cells, same scorers, but our test data was regenerated in between, and two of its cells still expected names from the old copy. In both, GPT-6 Luna read the current row correctly and was marked wrong. We left the score as measured rather than re-grade one model, so its 93.02% is slightly understated. The 0.92-point gap between the two Lunas is inside the run-to-run noise of this suite: read it as a tie.
Three runs per case absorb flukes, not variance. One run going the other way moves a single case by 33 points, so no claim below rests on one.

The headline: two Lunas vs Nova 2 Lite

Measured on the 201 test cases all three models ran, after we fixed a bias in how we were grading, the same yardstick, held to all three:

Model	Score	Cells	Trials
Amazon Nova 2 Lite	96.00%	201	579
GPT-5.6 Luna	93.94%	201	579
GPT-6 Luna	93.02%	201	579

The gap to Nova 2 Lite is real and we are not smoothing it. GPT-5.6 Luna refused a task it should have attempted, routed an indexed top-N query through a full-table pass, and once deferred to the user instead of finishing an export. GPT-6 Luna's misses are its own: asked to read a product, it suggested opening the table instead; asked to raise a price, it worked out the new value and then asked the user to open the row rather than staging the change. Those are agent-behavior losses, not formatting noise, and they are why Nova 2 Lite remains our floor.

But the shape of the result is the story. Two untuned models, on a benchmark tuned for someone else's models, landing within two to three points of the incumbent at a fraction of the cost.

What every call actually cost

Sticker prices say Luna should be cheap. The token counts say it is cheaper still. Here is every call we made to these models, priced at current Bedrock rates:

Model	Calls	$/call	vs GPT-6 Luna
GPT-6 Luna	2,519	$0.000246	1×
GPT-5.6 Luna	5,144	$0.000591	2.4×
Amazon Nova 2 Lite	6,303	$0.003022	12.3×
Claude Haiku 4.5	2,654	$0.003275	13.3×
GPT-5.6 Terra	751	$0.006458	26.3×

Two notes on the GPT-6 Luna row. Its price, $0.11 in / $0.55 out per million tokens, is derived rather than read off an AWS price table: AWS had not published a GPT-6 price row when we measured, so we used OpenAI's list price plus the 10% Bedrock adds on in-region and geo inference profiles, which is what we called. And its calls include a batch of short autocomplete calls that pull the average down a little; GPT-5.6 Luna's include autocomplete calls from its own August run too. Terra appears for cost only: we ran it across far fewer test cases than the others, and a score from a smaller sample does not belong beside a full one.

On sticker prices alone, GPT-5.6 Luna ($0.22 in / $1.32 out per million tokens) is already cheaper than Nova 2 Lite ($0.33 / $2.75) on both axes, and GPT-6 Luna halves it again. But the measured gap per call is wider than the stickers explain. The difference is caching.

The implicit prompt caching nobody configures

An agent loop re-sends a large, mostly-static prompt on every step: system instructions, tool schemas, conversation so far. Whether you pay full price for those repeated tokens is the single biggest cost lever in agent workloads.

On Bedrock's Converse API, prompt caching is normally opt-in: you place cache breakpoints in the request, and models without cache support simply pay full rate. The OpenAI models behave differently: caching is implicit and on by default. No breakpoints, no request changes, nothing to configure. It held on both transports we measured: GPT-5.6 Luna on Bedrock Mantle, GPT-6 Luna on Converse.

Share of input charged at the discounted cache rate:

Model	Cache-read share of input
Claude Haiku 4.5	95.5%
GPT-6 Luna	95.0%
GPT-5.6 Luna	94.5%
Amazon Nova 2 Lite	71.8%

Across 5,144 calls, GPT-5.6 Luna paid full price on fewer than six input tokens per call. The static prompt prefix was billed at the read rate almost every step, without a cache breakpoint anywhere in our requests. GPT-6 Luna did the same on Converse; its full-price average is higher, 72 tokens per call, only because its short autocomplete prompts have no prefix worth caching. Nova 2 Lite, on explicit Converse caching with a 0.25× read rate (vs 0.1× for the Lunas and Haiku), left 28% of its input at full price, and that, more than the stickers, is why the per-call gap is 12× and not 3×.

AWS shipped explicit cache breakpoints for GPT-5.6 the same day as the July price cut. Our numbers are the default behavior, what you get before reading that post. For an agent loop with a stable prefix, the default already captures about 95%.

Two transports, budget a day for these

When we first measured GPT-5.6, it was the first Bedrock family the Converse API could not reach: it lived only on the bedrock-mantle.{region} endpoint, speaking the OpenAI Responses protocol. That has changed. AWS now publishes us. and global. inference profiles for GPT-5.6 that Converse accepts, and GPT-6 launched on Converse. The bare GPT-5.6 model ID still goes to Mantle, and four things there cost us real debugging time:

temperature is rejected, not ignored. OpenAI's own endpoint silently drops unsupported sampling parameters; Mantle returns 400 unsupported_parameter. Our first full run failed everywhere on this before a single token was generated.
The base URL is /openai/v1, not /v1. The wrong path also returns a 400, one that reads misleadingly like an entitlement problem.
A fresh account gets 401s until the AWS Marketplace subscription for the model is active. The error text talks about authorization, not subscriptions; if you hit it, check Marketplace first.
Asking for a reasoning summary is a 400. When you set a reasoning effort, the OpenAI SDK asks for a detailed reasoning summary by default, and Bedrock now refuses the parameter, so every GPT-5.6 turn at low, medium or high effort failed until we sent an explicit "no summary". Nothing is lost by it: Bedrock returns no reasoning text for OpenAI models on either transport.

None of this is exotic once you know it, but no pricing table mentions any of it.

The full ladder: 12 models, one instrument, one day

After the July price cut we re-ran every model we tracked in one session (12 models, 39 scenarios, 3 runs each, $20.49 of Bedrock spend) so every row below is measured the same way on the same day. The table uses the 36 scenarios all twelve models ran. The three autocomplete scenarios are left out because at the time our autocomplete could not reach the GPT-5.6 models; that is fixed, and autocomplete has its own section below.

#	Model	Score	$/agent run
1	Claude Haiku 4.5 (1)	100.00%	$0.0100
2	Claude Sonnet 4.5 (ceiling ref)	99.69%	$0.0290
3	Amazon Nova 2 Lite (1)	97.22%	$0.0091
4	GPT-5.6 Luna	93.60%	$0.0024
5	GPT-5.6 Terra (reference)	92.82%	$0.0224
6	MiniMax M2 (2)	92.81%	$0.0178
7	Nova Pro (Gen 1)	90.66%	$0.0150
8	Nova Lite (Gen 1)	90.36%	$0.0013
9	DeepSeek V3.2 (2)	90.17%	$0.0508
10	Ministral 8B (2)	89.43%	$0.0104
11	Ministral 3B (2)	88.53%	$0.0082
12	Nova Micro	86.96%	$0.0008

(1) The two models this app ships against, months of prompt tuning went toward them specifically, and Haiku's perfect score should be read with that squarely in view. (2) No Bedrock prompt caching, so every step of an agent loop pays full input rate, which is how DeepSeek ends up costing 5× Claude Haiku per run while scoring seven points below it.

An agent run here is a full multi-step session (tool calls, queries, staged writes) and the dollar column is what one such session costs, averaged over the 100+ we ran per model.

Four readings we'd defend from this table, and one we wouldn't. GPT-5.6 Luna is the only model in the top half whose cost sits in the bottom half, the price-performance outlier of the ladder. Terra, the mid-tier GPT-5.6 at nearly ten times Luna's measured cost per run, lands 0.78 points below its cheaper sibling, that gap is inside the noise band, so the honest reading is a tie, and a tie is the damning version: on this workload, paying 10× for the bigger variant bought nothing we could detect. The caching column of the economy matters more than the sticker: Nova Lite Gen 1 at $0.0013/run is the budget surprise, and the no-cache tier is uniformly mispriced for agent work. And the two models we tuned for hold ranks 1 and 3, which is the tuning bias made visible, not a neutral ranking. What we would not defend: reading any two adjacent rows as meaningfully different, with three runs each, neighbours can swap on a single one going the other way.

Where GPT-6 Luna lands. It is not in the table because it did not exist on the day the table was measured, and a row from another day would break the one thing the table promises. On the same 36 scenarios, measured on September 23, it scored 90.12%. Two of those scenarios are the stale-data cells described above, where it answered correctly and was marked wrong. The rest of the gap is the misses named above, plus an email lookup where it searched with the wrong prefix, found nothing and stopped. Treat it as indicative: in its predecessor's range, not above it, at less than half the price.

One more thing the ladder run measured: our own suite, again. The three autocomplete scenarios initially scored 0% for all four no-cache models (36 runs of zero) and every one was rejected before the model generated a token: we were sending a request field those models don't accept. Same bug class we published about before, new field. Those 36 zeros measured our bug, not the models, so they are excluded from every number above, which raised those four scores by about 4 points each.

Then we fixed the builder and re-ran exactly those cells. DeepSeek V3.2 (which the broken suite had at 0%) scored 100% on all three autocomplete scenarios. The other three landed mid-range. Had we published the first run uncorrected, we'd have reported a model as incapable of autocomplete when it is, measurably, the best of the four at it. A benchmark that won't audit itself will happily rank vendors on its own bugs.

Autocomplete: both Lunas can do it now

When this post first ran, the GPT-5.6 models could not drive DynoTable's inline autocomplete at all: that path spoke only to Converse, and GPT-5.6 lived on Mantle. We moved autocomplete onto the same model layer the agent uses and measured again. Autocomplete here is the gray ghost text in the query editor: given the statement so far, the table schema and some stored values, complete the line.

Model	Autocomplete score	Median time per completion
Claude Haiku 4.5	98.48%	698 ms
GPT-6 Luna	96.97%	482 ms
Amazon Nova 2 Lite	96.21%	525 ms
Nova Micro	81.82%	345 ms

That is 22 autocomplete cases, three runs each, measured on September 23 with reasoning off. GPT-5.6 Luna scored 96.08% on the 17 cases the suite had in August; it has not been re-run on the five added since, so it gets no row here.

Getting GPT-6 Luna to that number taught us two things.

It would rather say nothing than guess, and that is correct. On its first run it left 7 of 18 cases blank on every try. Six of the seven were cases where the right completion was a table or column name the prompt never showed. Our prompt already said "emit nothing rather than guess", and GPT-6 Luna was the first model to take it literally. We decided it was right: autocomplete should never invent an identifier you did not write and your schema does not contain. The scoring changed to accept an empty completion there, and the prompt stayed.

It also refused to pick from values it was shown. Given a column and its four stored values, it still emitted nothing, reading "pick one of these" as the guess it had been told not to make. One sentence fixed it: choosing a candidate the statement or the schema actually shows is not a guess. Every model went up or stayed flat on the next run (Nova Micro by 8.6 points), and GPT-6 Luna's value-completion cases went to 100%.

We tried the obvious lever first. Raising GPT-6 Luna's reasoning effort to low or medium moved its score by half a point and roughly doubled its latency, so autocomplete runs with reasoning off. The whole final autocomplete run, four models on 22 cases, cost five cents.

What transfers if you're picking a cheap agent model

Benchmark on your workload, not on leaderboards. Luna's public scores and our agent scores rank models differently. The only number that predicts your bill and your failure rate is one measured on your own loops.
A new generation is not automatically a better agent. GPT-6 Luna tied GPT-5.6 Luna on our work and halved the cost. That is a good trade, but it is a price story, not a capability one.
Price the loop, not the token. Cache behavior differs per model family: read rates, write premiums, and whether caching is implicit or needs breakpoints. Two models with similar stickers can differ 5× per call.
A model being 2 points behind may not matter, where it loses does. Read the failing behaviors, not the aggregate. A wrong refusal is recoverable; a silent wrong answer is not. A blank autocomplete is better than an invented column name.
Audit your test data, not just your scorers. Two of GPT-6 Luna's "failures" were answers checked against data we had since replaced. Expected values drift like everything else.
Record what every call costs, from day one. Every number here exists because we kept that record. Estimating from published prices would have missed the caching story entirely.

GPT-6 Luna is in DynoTable's default model set, and GPT-5.6 Luna remains a verified, selectable model. Bring your own Bedrock credentials and pick either in the model picker. Claude Haiku 4.5 and Nova 2 Lite remain the models we tune against, and the gap is real. But if your bill is the constraint, two or three points is a very cheap trade.

Download DynoTable · How the AI agent works · The eval story behind our scorers

How we made cheap LLMs reliable at DynamoDB

DynoTable — Fri, 17 Jul 2026 20:30:32 +0000

DynoTable's AI agent runs on your own
AWS Bedrock credentials, which means you pick the model, and
many people pick a cheap one. So we don't tune the agent against a frontier model. Our floor is
Amazon Nova Lite, a model that costs a rounding error per query and
fails in ways frontier models don't.

On one Eval scenario (a join that needs the composite-key table as the
base), Nova Lite scored 0%. We didn't switch models, didn't add few-shot
examples, didn't fine-tune. We rewrote one validator error message to say
exactly what to do instead. It went to 100%, flipping the join on the
very next step.

The model was never the bottleneck. The message was.

The rest of the story is the validators that sit
around every tool call, the things we deliberately do not validate, and
the eval suite that decides every change. If you're building an
agent on a budget model — over DynamoDB or anything else —
most of it transfers.

Why cheap models fail at DynamoDB specifically

DynamoDB is a hostile target for a small model because the query surface
looks like SQL and isn't. PartiQL accepts
SELECT syntax but supports no JOIN, no GROUP BY, no DISTINCT, no
LIKE, and a model that learned SQL from the internet emits all of them
confidently.

The failures we actually observed, each from a real logged run:

Dropped limit arguments. Cheap models routinely omit the optional row limit on a query tool. The backend happily returns everything, a 200 KB tool result lands in the conversation, and the next model turn dies on the context ceiling, a ValidationException mid-loop, blamed on the wrong component.
Unsupported constructs. JOIN, GROUP BY, aggregates in PartiQL, statements DynamoDB will never run, emitted because they'd be correct on Postgres.
Identifier swaps. Nova Lite, given SELECT * FROM customers and the instruction "add a WHERE for Germany", would sometimes return SELECT * FROM orders WHERE …, a table the user never mentioned. The statement parses perfectly. Nothing syntactic catches it.
Tool misrouting. Asked about an attached file, Nova Lite called the open-tabs listing tool looking for files in tabs, it rarely used the tool-search mechanism at all, so anything not directly visible didn't exist.

None of these are hypothetical. Each one drove a specific guardrail below.

Validate at the tool boundary, and make the error a lesson

The architectural decision that mattered most was putting validation inside
the tool's execute step, not in the input schema. A schema rejection is a
dead end. The loop sees a type error and learns nothing. A tool that runs,
checks, and returns a structured error gives the model a normal tool result
it can react to on the next step.

And that error is written for the model, not for a human log. Our export
tool's errors read like this, verbatim:

startExport requires exactly one of {tabId} or {sql}.
FIX: call listOpenTabs and pass {tabId}, or pass {sql} with a single SELECT.

startExport {sql} must be a read-only single SELECT.
FIX: remove any INSERT/UPDATE/DELETE/DDL and pass one SELECT statement.

Query validation failures carry a validation: prefix, validation: parse-error: …, validation: partiql-unsupported: JOIN is not supported by DynamoDB PartiQL., which the system prompt establishes as
the signal to fix the statement rather than retry the same input. A
rejection message is a teaching signal. Before we adopted the FIX:
convention, the same failures ended with the model apologizing and telling
the user to click the export button themselves. After, it self-corrects and
completes the task.

The corollary took longer to learn: where the concrete example lives is a
design axis. If a mistake is caught by a validator at runtime, keep the
system prompt generic and let the dynamic error message carry the specific
tables and fix, the prompt stays small and the lesson arrives exactly when
it's needed. Only mistakes no validator can catch (like routing an
aggregate question to the right tool in the first place) earn a concrete
example in the prompt itself.

Diagram: view on dynotable.com

Parse the things you're going to reject

Rejecting JOIN with a generic syntax error at offset 27 teaches
nothing. So our hand-written PartiQL parser does something slightly
perverse: it deliberately parses constructs DynamoDB doesn't support
into a valid syntax tree, just so a walker can emit a specific, teachable
diagnostic. All verbatim, all model-facing:

JOIN is not supported by DynamoDB PartiQL.
GROUP BY is not supported by DynamoDB PartiQL.
TOP N is not supported. Use the API limit parameter.
IN list has 120 items. DynamoDB PartiQL caps IN at 50 values (PK column) or 100 values (non-key column).
IS NOT NULL is not supported in DynamoDB PartiQL. Use attribute_exists.
lower(path) is not a DynamoDB PartiQL function. Use … instead., with the replacement resolved per function.

Each message names the construct and the escape hatch. Paired with the
prompt rule "if PartiQL rejects an unsupported construct, switch to the
SQL workbench immediately", a cheap model recovers from its Postgres
instincts in one step instead of thrashing.

Know what NOT to validate

The schema-aware tier of our SQL validator resolves table and column
references against the real table descriptions the app already holds. Early
on it also flagged references to attributes DynamoDB didn't declare, which
sounds right and is exactly wrong. DynamoDB's attributeDefinitions only
lists key attributes, so the check rejected WHERE <non-key> = …, the
single most common legitimate query shape in existence. That check is now a
warning that never gates.

Every validator is a bet that the rejected shape is more likely wrong than
right. When the data model can't support the check, don't make the bet.

Result caps as behavior, not just safety

The fix for the dropped-limit blow-up wasn't "add the limit to the
prompt" (cheap models drop it anyway). Query tool results are capped hard, 10 rows or 5 KB, whichever comes first, always keeping at least the
first row, and the truncation notice is itself prescriptive:

Showing 10 of 4,200. To filter: re-run with WHERE.
To view in UI: emit proposeOpenTable.
To aggregate: use runWorkbenchSql GROUP BY.

The caps are intentionally far below what the context could hold. The goal
is behavioral: force the model to hand the user a real table view or an
exact aggregate, never to enumerate rows into chat. The recovery hint
names the exact tools, so the cap teaches the routing at the moment the
model needs it. The same envelope is mirrored byte-for-byte in the eval
suite, and a regression scenario pins truncated: true against a
10,000-item table so the cap can never silently disappear.

Evals are the arbiter

None of the above was designed on intuition and kept on faith. Every
prompt clause, validator message, and cap is gated by an eval suite that
runs real agent loops against a seeded DynamoDB Local, real tools,
real query execution, the production prompt builders and validators
imported directly rather than reimplemented, scored by binary checks on
the tool trace, the final state of the database, and the text.

What the evals caught that intuition missed:

A "cleaner" prompt genericization regressed a scenario from 100% to 0%. It read better to us. The floor model disagreed. Only the eval noticed.
Frontier-model prompt advice is actively wrong for cheap models. Published guidance says to soften CRITICAL/MUST language because big models over-trigger on it. Cheap models under-comply and need the firm version. We now eval-gate any borrowed advice instead of applying it on faith.
Strict tool assertions punished correct behavior. A scorer requiring the model to call the ask tool for clarification passed 19% across the model ladder, almost every "failure" was a model that had correctly asked for clarification in text. The scorer now accepts either. Score the user-facing intent, not the mechanism.
The model ladder earned its narrowing. We started broad. Mistral, AI21, GLM, Qwen, Nova Pro, more, and cut it to two rungs (Nova Lite, Claude Haiku) for reasons only real runs surface: one family cost ~10× per call because Bedrock offered it no prompt caching; Nova Pro hallucinated concatenated attribute names like customers.customerName on open-ended joins. And one family had to be blocklisted outright. Bedrock's unified API happily accepts tool definitions for models whose adapter then emits function calls as plain text, something the API metadata won't tell you. We found it with a paid smoke probe, not a spec.

Two disciplines keep the suite honest. Example tables never equal test
tables: prompt examples use neutral names that don't exist in the seed
data, and the evals run on different tables, so a pass proves the model
generalized the pattern, not that it memorized our example. And the $0
watch mode refuses recorded fixtures: replayed model outputs would
green-pass assertions that depend on real tool activity, so the free tier
validates wiring only, and anything that claims a score had to spend
real tokens on a real model.

The checklist, if you're building one of these

Pick your floor model first and eval against it always; frontier models hide your bugs.
Put validation in the tool's execute step; return errors the loop can act on, never schema dead-ends.
Write every rejection as what's wrong + FIX: exact next action, and interpolate the user's actual tables into it.
Parse what you intend to reject, so the diagnostic can be specific.
Audit each validator against your data model, delete the ones that reject legitimate shapes.
Cap tool results below what fits, and make the truncation notice route the model to the right next tool.
Run evals as real loops against a real (local) backend, reusing production code paths; keep example data disjoint from test data; make the eval suite the arbiter of every prompt and message change.

Does any of this matter if you use a frontier model?

Less often, but yes. The validators are load-bearing at every tier, a
frontier model still can't run JOIN on DynamoDB, and prescriptive errors
just get consumed faster. On our own runs the chip-emission behavior of a
frontier-class model once dropped to 0% under a prompt phrasing that
smaller models handled, the eval suite caught that too. Reliability
engineering isn't a small-model tax; small models just make the invoice
arrive sooner.

Where this runs

All of this ships inside DynoTable's agent and its
gated tool catalog: schema-aware
natural-language querying on your own
Bedrock credentials, exact whole-table aggregates, and writes that only
ever land in a reviewable staging area. External agents get the same
validated toolkit through the
MCP server, how we built that safely is
its own story, from OAuth to credential isolation.

And when you want determinism instead of generation, the query you'll
commit to code, skip the model entirely: the
Expression Builder assembles the
exact request by hand.

How we built a local SQL engine for DynamoDB

DynoTable — Fri, 17 Jul 2026 20:30:00 +0000

DynamoDB can export a 100 GB table but it cannot aggregate one. There is no
JOIN, no GROUP BY, no COUNT(*) (not slow versions of them, none) and even PartiQL, AWS's own SQL-ish surface, doesn't add
them. So every team ends up writing the same
throwaway script: paginate a Scan, fold rows into a map, print the
answer, delete the script.

DynoTable's Workbench is our answer to that script: a tab
where you write one real SELECT — multi-table JOIN … ON, WHERE,
GROUP BY, HAVING, DISTINCT, CASE, aggregates — against tables that
support none of it. This post is how it works under the hood, the parser
that silently lied to us, and why we later tore out the engine's memory
model.

Don't build a query engine

The core decision was refusing to write a relational executor. DynamoDB
pages stream into an embedded SQLite database, and SQLite, one of the most
tested query engines on earth, does the relational work:

Diagram: view on dynotable.com

Each DynamoDB item lands in SQLite as its raw typed envelope
({platform: {S: "ios"}}) in a single item column. A small user-defined
function unwraps attributes at query time, so your SELECT platform
compiles to a attr(item, 'platform', …) call. One detail in that
function is load-bearing: it wraps its JSON parsing in a catch, because the
SQLite binding turns one malformed row's parse error into an abort of the
entire prepared statement. Without the catch, one corrupt row would kill
the query.

The honest constraint we kept: DynamoDB's access-pattern physics still
apply. A JOIN's to-side must be a primary key or a GSI
partition key, the engine resolves joins by key lookup against the
stream, never by cross-product scan. If you need arbitrary joins on
non-key attributes, that's a modeling conversation,
not a query-engine feature.

The parser that lied to us

The first version used a popular off-the-shelf SQL parser. Over a few
weeks, four independent correctness bugs traced back to it:

SELECT DISTINCT was silently dropped. The parser accepted it and the emitter ignored it, every duplicate row came back. A user's bug report read: "shows a table of all the values, not counters."
Anything unhandled became the literal SQL NULL. CASE, CAST, scalar subqueries, the emitter's fallback for an unknown syntax node was return 'NULL'. Queries ran, returned confident wrong answers, and raised no error.
Identifier case didn't behave like SQL. SELECT PLATFORM FROM t returned nulls when the attribute was platform, the opposite of what every SQL database trains you to expect.
Autocomplete disagreed with the resolver, suggesting names the compiler would then fail to resolve.

The replacement, sql-parser-cst, won on one primitive the survey found
nowhere else: its tree preserves both the raw text and the
normalized name of every identifier, so the compiler can tell
platform from "PLATFORM". That single distinction lets one grammar
carry proper ANSI semantics: unquoted identifiers resolve
case-insensitively, quoted ones are the case-sensitive escape hatch,
exactly like Postgres or SQLite. It also carries a source range on every
node, so a diagnostic underlines the offending construct instead of the
whole statement.

And we replaced the return 'NULL' fallback with a rule we now treat as
policy: no silent NULL, ever. The emitter's default arm is a
precise-ranged error. Window functions get a message that says why, not
just no:

Window functions are not supported in Workbench.
They have undefined semantics on the joined-row materialization.

We accepted a pre-1.0 dependency, pinned to the exact version,
upgraded only by hand with the test suite as the gate. We evaluated
patching the old parser (it needed a parallel pre-tokenizer, parsing
every input twice), using the editor's syntax tree (token-level, no clause
structure), and hand-rolling (most of a SQLite parser, unbounded
maintenance). A four-way correctness failure beats all of those concerns.

Knowing what not to block

One diagnostic deliberately does not stop you. When a filter references
an attribute the schema can't confirm the casing of, we can't know the
canonical case. DynamoDB's server-side filters are case-sensitive and its
schema only declares key attributes. That emits a warning, and warnings
never disable Run. We learned this class of lesson the hard way in
our validator work: a gate that
rejects the most common legitimate query shape is worse than no gate.

The cap was the wrong shape

The first aggregation engine buffered scanned rows into an in-memory
SQLite with a size cap, 64 MB here, 250 MB there, and one path with no
cap that could OOM the app on a big table. Hit the cap and you got a
partial answer with an overflow flag.

The redesign started with a reframing: the competitor is the throwaway
script a developer would write instead. And a competent script doesn't
buffer-then-cap, it streams, folding each page into a running total
with bounded memory. The in-memory cap wasn't too small; it was the wrong
shape. Worse, a partial aggregate is wrong, not merely incomplete. The
moment that made this concrete: our own AI demo confidently narrated a
partial "top spenders" ranking as fact.

The rebuilt Compute engine works the way the script does, plus everything
the script never bothers with:

A planner classifies every query into one of three lanes: stream-fold (plain algebraic aggregates, COUNT/SUM/AVG/ MIN/MAX, folded page-by-page off the main process; size never gates a foldable query, it just takes longer), materialize (sorts, key-bounded joins, spilled to disk-backed SQLite, no memory cap), or an honest refusal that recommends the right heavyweight tool (DynamoDB's S3 export plus Athena) for the tail we can't serve.
The fold classification is deliberately narrow. A HAVING, an ORDER BY, a bare column next to the aggregate, any of them forces the materialize lane. A fold that ignored a clause and still reported "exact" would be precisely the wrong-but-confident bug this planner exists to prevent.
Exactness is part of the result. Aggregate columns show a partial badge while pages are still streaming, and drop it only when the scan has drained. Even arithmetic honesty is tracked: integer sums stay exact past 2⁵³ (stored as 64-bit integers), while a fractional sum that exceeds the float mantissa flags itself partial: precision rather than round quietly.
Fuses replace popups for machines. The interactive app asks before a five-million-item scan; the AI agent and MCP callers get scan budgets and page-boundary aborts instead. And the result envelope the model sees is deliberately trimmed, cost class and size estimates are withheld, because surfacing a stale guess invites the model to narrate it as fact.

One cost note that surprised people internally: for a one-off aggregate, a
live scan is roughly 6× cheaper than generating a DynamoDB→S3 export, which is why the script-shaped lane is the default and the warehouse is
the recommendation for repeated heavy analytics, not the reflex. (The
pricing calculator will price a full
pass of your own table.)

Is it safe to point SQL at production?

The Workbench is structurally read-only. The final SQL that reaches the
local engine passes a defense-in-depth gate that tokenizes and rejects
anything that isn't a single SELECT, as a contract violation, not a
user error, because the compiler should never have produced it. The SQLite
substrate runs with dangerous built-ins disabled, and writes to DynamoDB
have exactly one path in the entire app: the
reviewable staging area, which SQL cannot reach.

What transfers if you're building one

Don't write a query engine; write a faithful compiler onto one that already exists. Your bugs will live in the seams (identifier case, type envelopes, corrupt rows), not the join algorithm.
Demand quote-provenance from your parser. If it can't tell name from "NAME", you cannot implement SQL's case semantics, and your users will find out before you do.
Make "unhandled syntax" a loud error, never a default value. Silent NULL is how confident wrong answers ship.
Benchmark your design against the throwaway script your user would write. If the script streams and you buffer, you built the wrong shape.
Treat partial aggregates as wrong answers that need labeling, not partial credit.

The Workbench docs cover the day-to-day feature surface,
and SQL for DynamoDB maps what works across the
whole ecosystem. Or just download DynoTable, open a Workbench
tab with ⌘⌥Q, and run a JOIN against the database that
doesn't have one.

Why a database GUI should never write directly

DynoTable — Fri, 17 Jul 2026 20:29:59 +0000

Every database GUI has a moment where a click turns into a write against
production. We decided that moment shouldn't be the default. In DynoTable
an item edit, a staged delete and an AI agent's change do not
touch DynamoDB directly: each lands in a staging area as
a reviewable per-attribute diff, and ships only when a human commits it.
Two deliberate escape hatches still write straight through, and the
staging docs name them.

We built toward a git-like mental model: a staging area for review, and a
commit that behaves like git push --force-with-lease — it succeeds only
if the remote still looks the way you last saw it. This post is about the
cross-tab bug that reshaped the whole design, the refactor whose main
output was deleted code, and why AI agents turned a UX nicety into the
load-bearing safety wall.

Writes are diffs

Edits accumulate in a local SQLite-backed stage and render as diff cards (old value, new value, per attribute) in a side panel. Rows tint in the
grid so staged state is visible from the data, not just the panel. Commit
ships the staged set as DynamoDB transactions, chunked to
the service's limits (100 items per transaction, with byte budgets per
operation and per request), sequentially, with a 30-second timeout per
chunk.

The staging docs cover the daily workflow. What they don't
cover is what the stage is keyed by, which turned out to be the most
consequential decision in the system.

Keyed to the table, not the tab

The first version scoped each stage to the tab that created it. That
design produced a real bug: the AI's staging tool derived its target from
the active tab, and its guard skipped tabs that aren't table views. So
if you asked the assistant to fix a row while a SQL Workbench tab was
focused, the edit was staged into the Workbench's stage, and the "reveal
staged change" chip opened the wrong tab.

Worse, the commit lock was also per-tab. Two tabs viewing the same table
held two independent locks, meaning both could commit the same staged
rows to real DynamoDB concurrently. A double-commit race against
production, built into the data model.

The fix was to re-key everything by table identity ({profile, region, tableName}) instead of by tab:

One stage per table, visible from every view of it, surviving tab close and reopen. The AI can stage with no table tab open at all.
One commit lock per table. The double-commit race is unrepresentable.
The wrong-tab bug class is gone by construction: there is no tab in the key.

And re-keying deleted more code than it added. The startup sweep that
garbage-collected stages for closed tabs? A reviewer flagged it as
feature-destroying under the new model (stages no longer die with tabs) so it was removed outright. Discard-on-tab-close and its confirmation
dialog: removed. The only true orphan left is a deleted connection
profile, which cascades explicitly.

The migration itself was the repo's first row-mutating one: a
hand-written SQLite table rebuild that de-duplicated legacy per-tab rows
with a ROW_NUMBER() OVER (PARTITION BY …) window (newest edit wins) and
backfilled the new key with char(0) separators, byte-identical to the
runtime's key builder. Row-mutating migrations got their own
seed-then-migrate test suite that day.

`--force-with-lease`, for DynamoDB

A review UI is worthless if the thing you reviewed isn't the thing that
gets written. Between staging and committing, someone else may have
changed the row. So every commit operation carries
condition expressions that pin the write to the
exact snapshot you reviewed, optimistic locking,
attribute by attribute:

A create asserts the item doesn't already exist.
An update asserts every attribute you're changing still holds the value you saw when you staged it.
Even a removal asserts the attribute still equals its old value, if a teammate changed note from "old" to "new" while your removal of note sat staged, the commit must not silently delete their edit.

When a condition fails, DynamoDB cancels the whole transaction and tells
us which item drifted. That row gets a conflict banner, rebase against
the live value or abort, rather than a silent overwrite in either
direction.

And on any chunk failure, the committer halts. Committed chunks stay
committed, the failed chunk rolls back atomically, nothing further is
attempted. We deliberately rejected best-effort continuation: a review
tool that keeps writing past a conflict is applying a change set nobody
reviewed.

Diagram: view on dynotable.com

The refactor that deleted a subsystem

Commits are long-running: the app registers each one in a replay registry
so a renderer reload (or a second window) can re-attach and watch it
finish. Over time, three different code paths each attached two
observers per commit, and an entire arbitration mechanism grew up around
one question: which observer is allowed to release the commit lock? It had
its own scary name (ownsLockOnBeforeRegistration), a comment block
explaining an IPC ordering race, and a 230-line toast tracker.

The fix was a single owner, a Commit Session that attaches exactly
once per commit, owns the lock exclusively, projects progress into the
store, and guarantees its start call settles on every exit path, never
hangs, never rejects. The arbitration machinery and the tracker weren't
relocated; they were deleted. The memory benchmark that thrashes the
staging panel dropped about a third of its heap. The best code review
comment we got that month: "this PR is mostly red."

Two behaviors fall out of that ownership model that we consider
table-stakes for any tool that writes to production: an in-flight commit
survives a renderer reload (the session re-attaches and completes),
and it even survives your license flipping to read-only mid-commit, new
commits are blocked, but a write already in flight is observed to its end,
never abandoned half-applied.

Why the wire format is deliberately ugly

Staged values are stored as raw DynamoDB typed envelopes ({N: "42"}, {S: "42"}) not as friendly unmarshalled JSON. Two reasons.
The diff must be type-aware: {N: "1"} and {S: "1"} are different
values, and a primary-key hash built on unmarshalled values would collide
them. And the round-trip must be lossless: the SDK's unmarshalled number
wrappers don't survive JSON serialization into SQLite and back, and
deep-equality against user input breaks. The commit path uses the raw
client for the same reason, what you reviewed is byte-for-byte what gets
conditioned on and written.

Then the agents arrived

Staging predates our AI features, but it's the reason they could ship at
all. The assistant's write tool stages; its own description tells the
model, verbatim:

The user reviews + commits from the staging panel —
this tool never writes to DynamoDB directly.

There is no commit tool. Nothing to permission-gate or audit. The
primitive is absent.
The MCP server exposes the same
boundary structurally: its middle consent scope is literally named
"read + stage". A prompt-injected agent at that scope
can propose garbage, and the blast radius is a diff card a human reads.
And because commits carry per-attribute optimistic locks, even a stale
agent edit can't silently clobber a concurrent human one, it surfaces as
a conflict like everything else.

We wrote about making the agent's queries reliable;
staging is the other half, making its writes boring.

What to demand from any tool that writes to your database

A review step between intent and write, diffs, not confirmation dialogs.
Optimistic concurrency on the reviewed snapshot, including deletes and removals, never last-writer-wins.
Atomic batches with halt-on-failure, not best-effort continuation past a conflict.
A write path that survives a crash or reload without leaving a half-applied set.
For AI: staging as the only write primitive an agent has, a missing capability beats a guarded one.

The staging docs show the workflow, and
editing DynamoDB data covers the basics
it protects. Or download DynoTable, stage a few edits with
⌘S, and watch a bulk change become something you can actually
read before it happens.

What it took to build a safe DynamoDB MCP server

DynoTable — Thu, 16 Jul 2026 09:26:10 +0000

The Model Context Protocol makes it trivial to hand an
AI agent your database. That's the problem. Most DynamoDB MCP servers are a thin process
holding your raw AWS credentials with a write path and no review step.
We've written about why that pattern is risky and how to choose
safely from the user's side.

This post covers what it actually took to build the safe
version. DynoTable is a desktop DynamoDB client whose
MCP server exposes its gated AI toolkit to external agents (Claude Code, Cursor, Codex) without the agent ever touching AWS
credentials. Getting there meant shipping an OAuth 2.1
authorization server inside an Electron app, designing an identity type that makes
credential mix-ups unrepresentable, and deciding, more than once, that the
convenient default was the wrong one.

If you're building an MCP server around anything sensitive, these are the
decisions you'll meet too.

Loopback HTTP is not automatically safe

The server binds 127.0.0.1, which sounds safe and isn't sufficient. Any
web page you visit can attempt requests toward localhost, and DNS
rebinding lets a hostile page dress those up with a plausible Host. So
the first layer is an origin guard: reject any request carrying a real
web-page Origin, reject non-loopback Host headers, but allow
requests with no Origin at all, because legitimate CLI clients like
Claude Code don't send one.

That last clause is the honest part: an origin guard only blocks the
browser attack class. It cannot authenticate anyone. The bearer token is
the real gate, which raises the question of where tokens come from.

We shipped an OAuth 2.1 authorization server inside the app

MCP's remote-server auth story is OAuth 2.1, and for a local desktop
server there is no upstream identity provider to lean on. So the app is
the authorization server: dynamic client registration, PKCE (S256),
authorization codes, refresh tokens, revocation, and the RFC 8414 / RFC
9728 metadata documents that let clients discover it all.

Rules we set early and kept:

Don't hand-roll the protocol. The MCP SDK ships the full AS surface as a router; we implement only the storage/policy provider beneath it. One consequence we accepted: our MCP framework speaks one HTTP stack internally and the SDK router speaks another, so the AS runs as a second loopback listener, with the resource server pointing clients at it via protected-resource metadata. Two listeners is a scoped, explicit cost; re-deriving PKCE and token grammar by hand is an unbounded one.
Redirects are loopback-only (per RFC 8252 for native apps), and an invalid redirect never gets an error redirect, it gets a direct 400, so an attacker's URI is never a destination.
Authorization codes are single-use, a replayed code is an invalid grant, full stop.
Refresh can narrow scope but never widen it, and it re-issues the same identity payload verbatim, a refreshed token can't quietly acquire a different region.
Revocation is re-checked on every request, not cached at connect, clicking "Revoke" in Settings kills the client's next call.

Development builds use a simpler auth path, built so it cannot exist in a
release binary, an unauthenticated full-scope token in shipped software
would be a local backdoor behind an origin guard that deliberately admits
no-Origin requests.

One connection, one AWS identity — carried whole, never guessed

An external agent connects to a profile, not
to "DynoTable". Each connection is bound to one AWS profile and one
region, backed by its own non-shared DynamoDB client, so two agents on
different profiles can't bleed into each other.

The binding started life as loose fields, awsProfile, region,
profileId, an optional local port, re-declared across every record on
the path. It's now one discriminated-union identity type with two
arms: online (profile + region + id) and offline (local port + id,
for DynamoDB Local profiles). Offline-ness is
the discriminant itself, so an online identity without credentials or an
offline one carrying a region is a type error, not a runtime surprise.
That one type travels intact through consent → token → grant → every
request.

Diagram: view on dynotable.com

Two consequences we consider load-bearing:

Region is frozen at consent. The user approves "profile X in region Y", and that tuple is pinned on the token, surviving refresh, never re-resolved from mutable state on the hot path. Editing the profile's region requires re-consent. The alternative, resolving region per-request or falling back to a default, is how an agent quietly ends up querying us-east-1.
Malformed tokens are a 401, never a coercion. If a token's identity claims don't parse into a valid arm, the request is unauthorized. No 'default' profile, no default region, no empty string. Every place the old code would have guessed is now a hard failure.

Consent is a product surface, not a dialog box

The first consent prompt was the platform-native message box. It froze
the Electron main process while open, couldn't match the app's design
system, and couldn't even be screenshotted for docs. It's now an in-app
modal: the connecting client's name, a profile picker over exactly the
profiles the user chose to expose, and three scopes offered
narrowest-first, read-only, read + stage, full. Expired or duplicate
consent requests settle as denied rather than hanging the OAuth flow.

The picker has a small trust boundary of its own: a client may hint a
profile in the authorize URL, but the grant is minted from what the user
actually selected, validated against the snapshot they were shown, a
forged hint can't bind a profile that was never on screen.

We're equally explicit about what consent does not give you:
authorization is scope-only, approved once per connection. The in-app
assistant's per-call permission prompts do not apply to MCP traffic, a
leaked full-scope token can write (into staging) without a human seeing
each call. Short token lifetimes, per-client revocation, an always-on
audit trail marking every MCP-originated action, and read-only as the
default offer are the mitigations. Writing that down as a residual risk
was more useful than pretending the consent modal closed it.

Guardrails for headless work

An external agent has no renderer, no confirmation popups, no user
watching. Everything interactive needed a headless equivalent:

Live license clamping, per call. The grant stores the scope the user approved; the effective scope is derived on every tool call from the app's current license state, a read-only license clamps a full grant down, a signed-out state rejects with 401 before any token branch (so the dev token can't bypass it), and a mid-session reactivation re-widens without re-consent. One deliberate asymmetry: in-app export stays available under a read-only license (your data is your data), but headless bulk export over MCP is clamped off, an interactive portability right and an agent-driven egress channel are different trust surfaces.
Scan budgets instead of confirmation popups. In the app, a whole-table read asks first. Headless, an items/bytes/duration budget bounds every scan, and SQL over tables streams through a disk-backed engine rather than an in-memory cap.
Disconnect aborts honestly. If the client drops mid-scan, the server aborts at the next page boundary (never mid-statement) and disposes the temporary state.
MFA completes over the wire. When AWS credentials need an MFA code and the client supports MCP elicitation, the server elicits the 6-digit code through the agent's own UI. Claude Code prompts the human, and retries. SSO is deliberately excluded from this path: it needs a browser device flow, and pretending otherwise would just be a worse error message. Concurrent calls needing the same credentials coalesce into one prompt.

Is exposing a database over MCP safe at all?

Our honest answer: only if the server is designed around the assumption
that the agent is confused at best and adversarial at worst.
Prompt injection makes an agent's intent untrustworthy, which is why the
architecture never relies on the agent behaving: credentials stay in the
app, writes only ever land in a reviewable staging
area, scopes clamp what a call can do regardless of what
the model asks for, and every action is audited. The
connect-side guide covers what that means
in practice for each client.

What to demand from any MCP server that touches your database

Where do the credentials live, in the agent's process, or behind the server?
Is there per-connection consent with real scopes, or does one config file grant everything?
Can a write execute without a human review step?
Is the identity (profile, region) pinned at consent, or resolved from defaults at call time?
What happens on a malformed or revoked token, hard failure, or a fallback?
Is there an audit trail that distinguishes agent-originated actions?
What bounds a runaway scan, and what happens when the client disconnects mid-operation?

If a server can't answer those, the convenient integration is the risky
one. For sizing what an unbounded scan would actually cost you, the
pricing calculator is sobering, and if you'd rather see the safe version running than read about it,
download DynoTable, flip on the MCP server, and connect a
client at read-only scope in under a minute.

The Best DynamoDB GUI Clients in 2026

DynoTable — Sat, 04 Jul 2026 10:38:10 +0000

There is no single "best" DynamoDB GUI; there are tools built for different jobs. This roundup covers the clients that actually matter in 2026, with every pricing and platform claim re-checked against the vendor's own page on 2026-08-06 (the one exception is dated inline). One of the tools is ours; we say so where it matters and list what it does not do.

What is the best DynamoDB GUI?

It depends on the job: NoSQL Workbench is the best free client for designing
tables, dynamodb-admin for browsing a local Docker table, Dynobase the
most feature-complete paid incumbent, and DynoTable the pick when your
questions are SQL-shaped — JOIN, GROUP BY, and aggregates that PartiQL-only
tools can't run. Every claim below was re-checked against vendor pages on
2026-08-06.

Best free DynamoDB GUI: NoSQL Workbench for designing tables, dynamodb-admin for peeking at a local table, DocKit for a free open-source live-data client.
Best paid daily driver: Dynobase remains the most feature-complete incumbent; DynoTable if your questions are SQL-shaped (JOIN, GROUP BY, aggregates that PartiQL tools can't run).
Pricing moved this year: Dynomate dropped its $199 one-time license for $10–$29/mo subscriptions (checked 2026-08-06). Re-verify prices before budgeting; ours were all checked on that date.
Docker/local: dynamodb-admin against the amazon/dynamodb-local container is still the standard answer, and it's free.

Every DynamoDB GUI compared

Prices and platforms verified against each vendor's own page on 2026-08-06. A dash means not offered or not verifiable from the vendor's docs. (TablePlus's price and platforms are from that date too; only its DynamoDB-connector capabilities are the older 2026-06-10 check, flagged in its section below.)

Tool	Price	Platforms	Visual query builder	Live data ops	Modeling	JOIN / GROUP BY / aggregates
NoSQL Workbench	Free	macOS / Win / Linux	Operation builder	Limited	Strong	No
Dynobase	$9/mo billed annually, or $199 once	macOS / Win / Linux	Yes	Strong	Partial	No (PartiQL only)
Dynomate	Free tier; $10–$29/mo billed annually	macOS / Win / Linux	Request editor	Strong	No	No (SQL over exports, beta)
DbVisualizer	Free (limited); Pro $199 first yr, $89 renewal	macOS / Win / Linux	Yes (generates SQL)	Solid	No	No (PartiQL only)
DocKit	Free (Apache-2.0)	macOS / Win / Linux	Yes (13+ operators)	Strong	No	No (PartiQL only)
dynamodb-admin	Free (MIT)	Any (Node)	—	Local only	No	No
DynamoIt	Free (GPL-3.0)	Any (JVM)	Basic	Basic	No	No
TablePlus	$99–$129 once (1 yr of updates)	macOS / Win / Linux	Filter only	Beta (view/filter)	No	No
DataGrip	Paid IDE	macOS / Win / Linux	No	Viewer + PartiQL	No	No (PartiQL only)
DynoTable	Free read-only; from $9/mo billed annually	macOS* / Win / Linux	Yes (index picker)	Strong	No	Yes (SQL Workbench)

* DynoTable's macOS build is Apple Silicon only. Its free plan requires an account and is read-only; see pricing.

How to choose a DynamoDB UI

Pick based on the job you actually do most:

Live data ops: browse, filter, and edit items in real tables, fast, without the AWS Console. This is the daily-driver case.
Data modeling: design tables, sort keys, and GSIs around your access patterns before you write code.
Analytics-shaped questions: JOINs, GROUP BY, aggregates. DynamoDB's own query surface does not do these (more below), so the tool has to compile around the limitation.

Your main job	Reach for
Design tables / GSIs before coding	NoSQL Workbench
Browse & edit live data daily	Dynobase or DynoTable
Git-shareable saved query collections	Dynomate
One GUI for DynamoDB + Elasticsearch / MongoDB	DocKit or DbVisualizer
Just see what's in a local table	dynamodb-admin / DynamoIt
Already live in a JetBrains IDE	DataGrip
JOIN / `GROUP BY` / aggregates over your data	DynoTable (SQL Workbench)

Tip

Most teams end up with two tools, not one: a modeler for design time and a data-ops client for everything after. That split is normal; don't expect a single GUI to be excellent at both.

AWS NoSQL Workbench

Free · macOS / Windows / Linux · modeling-first

NoSQL Workbench is AWS's own "cross-platform, client-side GUI application" and it costs nothing. Its data modeler designs tables and GSIs from scratch or from an imported model, lets you "visualize your access patterns as real DynamoDB operations" against sample data, then commits the model to DynamoDB Local or a real account.

The operation builder is the live half: "view, explore, and query live datasets", with projection and condition expression support, sample-code generation in multiple languages, and table cloning between accounts, regions, and DynamoDB Local. The download includes DynamoDB Local, so offline modeling works out of the box.

It's the best free way to design a table. Treat it as a development and modeling tool — browsing or editing real data all day in it is slow going. Reach for it when you're modeling your single-table design, not when you're debugging a row at 2am. Our NoSQL Workbench alternative page covers the day-to-day gap.

Verdict: the free modeling tool every DynamoDB team should have installed; pair it with a data-ops client.

Dynobase

$9/mo billed annually ($108) or $199 one-time · 7-day trial · macOS / Windows / Linux

Dynobase is the established paid desktop client and still the most feature-complete commercial option. As of 2026-08-06 its pricing page lists a Solo plan at $9/month billed annually ($108), a one-time $199 lifetime license (struck from $249), and a Team plan at $79/month billed annually, all behind a 7-day trial with no credit card.

It covers fast exploration, inline editing, a visual query builder (its headline feature, and the axis every rival gets measured on), import/export in CSV or JSON, code generation for JS/TS, Rust, Go, and Python, and local DynamoDB including Docker distributions.

Two things to weigh. It's closed-source, and its SQL surface is AWS PartiQL pass-through, so it inherits PartiQL's limits: no cross-table JOIN, GROUP BY, or aggregates. And its changelog lists "Dynobase 2.5.0 Beta" at the top with no release dates (checked 2026-08-06); several rivals have built entire comparison pages on its release cadence, so judge maintenance for yourself before a lifetime purchase.

Verdict: the safe, broad commercial pick if the license cost is fine. Our Dynobase alternative page covers where DynoTable differs, chiefly the SQL Workbench and EUR/EU-tax billing.

Dynomate

Free tier + $10–$29/mo billed annually · 14-day trial · macOS / Windows / Linux

Dynomate grew popular as a Dynobase alternative, and its distinctive feature is a request-collection workflow: save queries, chain one request's results into the next with environment variables, organize them in folders, and share the collections through Git. It also does AWS SSO and MFA sign-in inside the app, multi-profile and multi-region tabs, DynamoDB Local, and CSV/JSON export.

Its pricing changed in 2026. When we checked on 2026-06-10 it sold a $199 one-time license; as of 2026-08-06 the pricing page lists a free Community tier and subscriptions at $10, $18, and $29 per month billed annually, with a 14-day trial and a 30-day money-back guarantee.

One honest detail its "SQL console" label hides: it queries DynamoDB table exports with SQL (marked Beta), not your live tables. For Git-friendly, reviewable query collections it's a strong pick; our Dynomate alternative page covers where DynoTable differs.

Verdict: the pick if a shared, versioned library of saved requests is the feature you're shopping for.

DbVisualizer

Free edition (limited) · Pro $199/user first year, $89 renewal · 21-day trial · macOS / Windows / Linux

DbVisualizer is the veteran multi-database SQL client, and its DynamoDB support is real: it browses tables, partition and sort keys, and local and global indexes, edits items including maps and sets with mixed content, and runs PartiQL through its SQL Commander with a visual query builder that generates the statements for you.

Pricing splits into a free edition with a limited feature set and a Pro tier at $199 per user for the first year ($89 renewal), with a 21-day trial and no credit card. If your week spans Postgres, MySQL, and DynamoDB, one tool for all of them is a fair trade.

The trade-off is the same one every generalist makes: DynamoDB is one of dozens of supported databases, the querying is single-table PartiQL, and there's no DynamoDB-native modeling or cost awareness.

Verdict: worth a look if DynamoDB is a side database in a relational-heavy week, not your main store.

DocKit

Free (Apache-2.0) · open-source · multi-datastore · macOS / Windows / Linux

DocKit is a free, open-source desktop client built on Tauri (Rust), which keeps the install small, and it spans five datastores: Elasticsearch, OpenSearch, DynamoDB, MongoDB, and EasySearch. For DynamoDB it has a query builder with primary-key filtering and 13+ operators, plus a PartiQL editor with autocomplete and inline item CRUD.

Its "Agentic Data Studio" AI assistant is bring-your-own-key across OpenAI, Anthropic, DeepSeek, Ollama, and LM Studio, so your data and keys stay on your machine.

Its breadth is also its trade-off: DocKit is a generalist across five stores rather than a DynamoDB-native client, and its DynamoDB querying is single-table PartiQL. No cross-table JOIN, GROUP BY, or aggregates, and no modeling.

Verdict: the best free option if your stack is broader than DynamoDB and price matters.

dynamodb-admin and DynamoIt

Free / open-source · local-focused

For local development there are good free options:

dynamodb-admin is a small MIT-licensed web GUI for DynamoDB Local, dynalite, and LocalStack. Install it globally and point it at your local endpoint:

  pnpm add -g dynamodb-admin
  dynamodb-admin --dynamo-endpoint=http://localhost:8000

By default it sets dummy credentials (key/secret, region us-east-1) so it connects straight to a local endpoint, which makes it the standard answer for "I just need to see what's in my local table." For a deeper walkthrough of endpoints and dummy creds, see connecting to DynamoDB Local; for how it stacks up as a daily tool, see the dynamodb-admin alternative page.

DynamoIt is a free, GPL-3.0 JavaFX desktop viewer that reads your AWS CLI profiles for quick browse/edit work with no login step. It auto-picks scan vs query, paginates, and supports local DynamoDB; the README notes you need at least Java 17 (and Maven) to build and run it.

Verdict: both are great for local and light use and cost nothing; neither aims to be a production workbench.

Warning

Local-only GUIs are excellent for development, but pointing a bare admin UI at a production table is risky: there are no guardrails around a full-table Scan, and an accidental scan on a large table burns read capacity and money. Use a client that shows query cost before you run it.

TablePlus and DataGrip

Generalist SQL clients with partial DynamoDB support

These are excellent relational clients whose DynamoDB support is bolted on rather than native.

TablePlus added an undocumented DynamoDB connector in 2025: you can view tables and filter items with its visual filter builder, but there's no PartiQL/SQL query editor and DynamoDB has no page in TablePlus's official docs (as of our 2026-06-10 check). It is a perpetual licence — $99 for one device, $129 for two, each with a year of updates — and ships for macOS, Windows and Linux (tableplus.com, checked 2026-08-06).
DataGrip added DynamoDB in version 2023.3: data is viewable in the data viewer, "tables with keys and indexes are now introspected", and PartiQL is supported in the code editor. Useful if you already live in a JetBrains IDE; still a viewer-plus-PartiQL surface, not a DynamoDB-native tool.

Verdict: fine as an occasional viewer if you already pay for them; a purpose-built client fits the data model better when DynamoDB is a primary database. See the DataGrip comparison and the TablePlus comparison.

DynoTable

Free read-only plan · from $9/mo billed annually · 30-day trial · macOS (Apple Silicon) / Windows / Linux

Full disclosure: this is our tool. DynoTable is a desktop DynamoDB GUI client whose differentiator is a SQL Workbench that compiles real SQL — INNER/LEFT JOIN, GROUP BY, and aggregates like COUNT, SUM, and AVG — down to DynamoDB's actual Query/Scan operations.

That matters because DynamoDB's own SQL surface can't. Per the PartiQL SELECT reference (checked 2026-08-06), the grammar is SELECT … FROM … WHERE … ORDER BY only: no JOIN, no GROUP BY, no aggregate functions. Every "supports SQL" claim in the table above is PartiQL underneath and hits this wall; the PartiQL vs SQL guide walks through exactly where.

-- Runs in the DynoTable SQL Workbench (NOT in PartiQL):
SELECT c.country, COUNT(*) AS orders, SUM(o.total) AS revenue
FROM orders o
INNER JOIN customers c ON o.customerId = c.PK
GROUP BY c.country
ORDER BY revenue DESC

The Workbench is honest about its rules, because they ARE DynamoDB's rules: one SELECT at a time, INNER/LEFT JOIN only, and a join target that must be a partition key or GSI partition key. That's SQL within DynamoDB's access-pattern rules, not a magic layer over a full scan.

The daily-driver basics are covered the same way:

Visual query builder: pill-based filters with an index picker and automatic Query-vs-Scan derivation, so you can see when a filter degrades to a scan.
Query cost up front: in the SQL Workbench and the PartiQL editor, a status bar estimates items and read cost before you run, where the plan is known. That's the guardrail the warning about production scans above is asking for.
Staged writes: edits stage locally into a reviewable diff before anything commits to DynamoDB. (One caveat, stated because it's true: PartiQL DML executes directly with a warning, it does not stage.)
Credentials done right: the five AWS credential kinds auto-detected from ~/.aws, SSO device flow in-process, MFA TOTP in-app, and DynamoDB Local profiles.
AI on your own Bedrock: the agent runs in your AWS account and cannot write to DynamoDB directly; its writes go through the same staged diff you review. You pay AWS for the tokens.

Your table data never touches a DynoTable server: reads and writes go from the app to your AWS account, and your AWS credentials never leave your machine.

What DynoTable does not do: it creates and deletes tables and global secondary indexes and configures TTL, capacity and deletion protection, but there are no backups or point-in-time recovery, no streams configuration, and no CloudWatch monitoring — those stay in the AWS console. There's no bulk update. A profile is one region, the macOS build is Apple Silicon only, and a license covers 2 machines. If those are your daily needs, pick from the tools above.

Pricing: a free read-only plan (account required), and paid from $12/month, or $9/month billed annually; the 30-day trial needs no credit card. See DynoTable as a DynamoDB GUI for the full category comparison.

Verdict: the right pick when your questions are analytics-shaped and PartiQL leaves you stuck; the wrong pick if you need table administration.

What is the best DynamoDB GUI client?

It depends on the job. NoSQL Workbench is the best free modeling tool, Dynobase is the most feature-complete commercial client, Dynomate is the pick for Git-shareable query collections, DocKit is the best free option if you also work across Elasticsearch or MongoDB, dynamodb-admin is the standard for local development, and DynoTable adds the SQL Workbench that runs JOINs, GROUP BY, and aggregates that PartiQL can't. Start from the work you do most and the choice usually makes itself.

Is there a free DynamoDB GUI?

Yes, several. AWS NoSQL Workbench is free and cross-platform (and the safest "official" choice); DocKit is free, open-source, and a genuine live-data client; dynamodb-admin and DynamoIt are free and open-source for local work; and DbVisualizer and Dynomate both ship free tiers with limited feature sets (verified 2026-08-06).

None of the free options run cross-table JOIN/GROUP BY/aggregates; they query DynamoDB through single-table PartiQL. For relational-shaped questions over DynamoDB data, that's where a paid SQL Workbench earns its keep.

What's a good DynamoDB GUI for Mac, Windows, or Docker?

All the desktop clients here ship for macOS, Windows, and Linux; note DynoTable's macOS build is Apple Silicon only, while DbVisualizer and NoSQL Workbench also cover Intel Macs. For Docker-based local setups, dynamodb-admin is the usual pick: point --dynamo-endpoint at the amazon/dynamodb-local container's exposed port. DynoTable and Dynobase also connect to local endpoints, including LocalStack.

Can a DynamoDB GUI run real SQL, with JOINs and aggregates?

Not through PartiQL. DynamoDB's PartiQL SELECT grammar has no JOIN, GROUP BY, or aggregate functions (per the AWS reference, checked 2026-08-06), so any client that "supports SQL" via PartiQL — Dynobase, DataGrip, DbVisualizer, DocKit — hits the same wall. A tool has to plan and compile those queries into DynamoDB's Query/Scan operations itself; DynoTable's SQL Workbench is built to do exactly that. If you only need the raw filter or key conditions for a single API call, the DynamoDB Expression Builder generates the correct FilterExpression / KeyConditionExpression without any SQL surface at all.

Do I still need a GUI if I have the AWS Console?

Many people switch precisely because of the Console's limits: weak filtering, clumsy pagination, and no real export. A purpose-built GUI adds fast filtering, inline editing, query building with cost visibility, and one-click export. The DynamoDB Console alternative page walks the gap feature by feature.

Concepts the right tool should make easy: query vs scan, single-table design, and the PartiQL vs SQL gap that the SQL Workbench fills (with worked PartiQL examples).
Free tools that run in your browser, no install: the DynamoDB JSON converter and the Expression Builder.
Head-to-head pages: DynamoDB GUI client overview, Dynobase, Dynomate, NoSQL Workbench, DataGrip, and TablePlus.
Download DynoTable and run a JOIN against your own tables.

Pricing and version claims verified 2026-08-06 against each vendor's own pages; TablePlus's DynamoDB-connector capabilities are the older 2026-06-10 check, flagged where they appear. Re-check before relying on any of them. Product names are trademarks of their respective owners; referenced here for identification only.

DEV Community: DynoTable

DynamoDB Limits and Quotas, Verified on the Live Service

What are the DynamoDB limits?

How these numbers were established

Verified limits

What the probes turned up

The 1 MB page, which raises nothing at all

Quotas we did not probe

Throughput and partition limits

Which limits you should design around

FAQ

How many writes per second before a new DynamoDB table throttles?

The throttle is a 400, and it names the wrong suspect first

You cannot measure this from a laptop

Three runs died before one worked, and DynamoDB was innocent every time

What the reads did

Half an hour of pressure does not double the ceiling

What transfers if you measure a cloud service yourself

The reference pages this feeds

Why we hand-wrote a PartiQL parser for DynamoDB

Regex was fine, until it wasn't

Nobody had built one

Swapping the engine without breaking the plane

The bugs that only garbage finds

A test suite you can audit against AWS's docs

What transfers if you're building one

Your agent doesn't need every tool in its context

A tool the model never calls still costs you

We built a search tool. The floor model wouldn't call it.

The race that would have made discovery silently useless

Three searches, then stop

One row per tool, everything else derived

What transfers if you're building one

Where this runs

GPT-6 Luna vs GPT-5.6 Luna vs other cheap models: benchmarked on real agent work

What this benchmark is (and is not)

The headline: two Lunas vs Nova 2 Lite

What every call actually cost

The implicit prompt caching nobody configures

Two transports, budget a day for these

The full ladder: 12 models, one instrument, one day

Autocomplete: both Lunas can do it now

What transfers if you're picking a cheap agent model

How we made cheap LLMs reliable at DynamoDB

Why cheap models fail at DynamoDB specifically

Validate at the tool boundary, and make the error a lesson

Parse the things you're going to reject

Know what NOT to validate

Result caps as behavior, not just safety

Evals are the arbiter

The checklist, if you're building one of these

Does any of this matter if you use a frontier model?

Where this runs

How we built a local SQL engine for DynamoDB

Don't build a query engine

The parser that lied to us

Knowing what not to block

The cap was the wrong shape

Is it safe to point SQL at production?

What transfers if you're building one

Why a database GUI should never write directly

Writes are diffs

Keyed to the table, not the tab

--force-with-lease, for DynamoDB

The refactor that deleted a subsystem

Why the wire format is deliberately ugly

Then the agents arrived

What to demand from any tool that writes to your database

What it took to build a safe DynamoDB MCP server

Loopback HTTP is not automatically safe

We shipped an OAuth 2.1 authorization server inside the app

One connection, one AWS identity — carried whole, never guessed

Consent is a product surface, not a dialog box

Guardrails for headless work

Is exposing a database over MCP safe at all?

What to demand from any MCP server that touches your database

The Best DynamoDB GUI Clients in 2026

What is the best DynamoDB GUI?

Every DynamoDB GUI compared

How to choose a DynamoDB UI

`--force-with-lease`, for DynamoDB