Changelog

The execute_partiql MCP tool accepts ConsistentRead. Omitting it was harmless while the field only chose a rate; it now also decides whether a select qualified by a GSI is rejected, so an agent had no way to reach either behaviour.

BatchExecuteStatement accepts ReturnConsumedCapacity and reports capacity, which it previously had no way to do at all. Per-table entries with index arms, aggregated across the batch. A failed statement is still charged the write it attempted, sized on the larger of the row already stored and the item it carried; a batch in which nothing succeeds reports no capacity, and a table whose statements all failed is omitted entirely. Captured against eu-west-2.

Breaking (behaviour): numbers are sized the way DynamoDB sizes them, so consumed capacity moves. Captured byte-exact against eu-west-2 by bisecting the 400KB gate: a number costs one byte, plus ceil(integer significant digits / 2) and ceil(fraction significant digits / 2), over the value with leading and trailing zeros trimmed. The old measure was wrong in both directions. It charged for zeros DynamoDB trims, so 0.0000001 was sized at 5 bytes rather than 2; it rounded the halving down where DynamoDB rounds up, so every number with an odd count of significant digits was a byte light; and it never charged for a minus sign, which costs a byte, so every negative number was light too. Both fed consumed capacity on every write, table_stats, the query and scan byte budgets, and index capacity, so those figures change. An item sitting on the 400KB boundary can flip either way with it.

Breaking (behaviour): UpdateItem measures the limit the way DynamoDB does, which is not the way a put is measured. It applied the same ceiling to the finished item as PutItem, where DynamoDB leaves the key attributes out of the figure and charges a fixed amount per action: three bytes for the update, nineteen for each action that writes a value, two for each that clears one, and nothing for the value written, the attribute name, or the expression text. With a one-character key that puts an update's ceiling nineteen bytes below a put's, so an item can be reachable by PutItem and out of reach by UpdateItem. Updates in that band used to succeed and now fail. Two forms are charged less than DynamoDB charges them, so the engine still accepts a little more rather than less: assigning through a list index costs a byte more, and an arithmetic assignment such as SET n = n + :one costs fifty more. The legacy AttributeUpdates parameter is charged on the same shapes, inferred from the expression form rather than captured separately.

The finished item is held to the 400KB limit as well, so the rule is max(item, item - key attributes + action cost). Taking the key out never buys back more than the actions cost: once the key attributes reach that cost the item's own size binds, and the ceiling sits flat at 400KB however long the key gets. With a 20-byte key the two meet exactly. Measured across key lengths from 1 to 1,024 bytes, DynamoDB never accepts a finished item above 409,600.

Breaking (behaviour): TransactWriteItems reports an oversized item as DynamoDB does, where both actions used to come back as a cancellation carrying the put wording. A put's size is knowable from the request, so it is now rejected up front with a top-level ValidationException before the transaction opens; an update's depends on the stored item, so it stays a ValidationError cancellation reason, now reading Item size to update has exceeded the maximum allowed size. Code matching on the error type for an oversized put in a transaction sees a ValidationException where it saw a TransactionCanceledException. A transacted update is measured flat against the resulting item, without the key exclusion and per-action cost the standalone UpdateItem carries, so an item UpdateItem refuses can still be written inside a transaction. Captured against eu-west-2.

Breaking (behaviour): the PartiQL write surfaces hold the 400KB item-size limit, where they did not check it at all. INSERT and UPDATE computed an item's size, handed it to storage and never compared it to anything, so ExecuteStatement, BatchExecuteStatement and ExecuteTransaction would store an over-limit row and report its size in table statistics. Both are measured flat against the item, captured against eu-west-2 at a ceiling of 409,600, and report in DynamoDB's words: Item size has exceeded the maximum allowed size for an insert, Item size to update has exceeded the maximum allowed size for an update. A PartiQL update is not charged the key exclusion and per-action cost that the standalone UpdateItem carries, so the two surfaces genuinely differ on the same finished item. Statements that used to succeed now fail.

Breaking (behaviour): the three PartiQL surfaces reject a ReturnConsumedCapacity outside INDEXES, TOTAL and NONE, as GetItem, PutItem, UpdateItem, DeleteItem, Query and Scan already did. They derived their requests rather than validating them, so a typo was read as NONE and reported nothing. It now also decides whether a write sizes its indexes, so the same typo quietly skipped that too. A request carrying an unrecognised value used to succeed and now fails.

Breaking (behaviour): BatchExecuteStatement and ExecuteTransaction now reject two request shapes they used to accept, matching DynamoDB. A batch or transaction may not mix reads and writes, and may not name the same item twice, reads included. Both are rejected up front with a top-level ValidationException before any statement runs; a request that previously succeeded in either shape now fails. An unparseable member is unaffected and still reports against itself while the rest of the batch runs. Captured against eu-west-2.

The four checks cost about 7% on a 25-statement BatchExecuteStatement, measured against 958e340.

Breaking (Rust API): the PartiQL parser's public types moved with the index-qualifier work. Every partiql::parser::Statement variant is now #[non_exhaustive], and Select, Update and Delete carry an index_name, so a downstream match needs a .. and construction goes through Default or deserialisation. partiql::parser::parse returns ParseError rather than String, because which envelope a rejection takes is part of the observable contract and the caller cannot tell from the text. partiql::parser::CompOp is a re-export of the condition engine's operator rather than a second enum of the same shape. partiql::executor::execute_page takes the statement's ConsistentRead, which now decides both the rate a read is charged at and whether a GSI-qualified select is rejected at all. Source-breaking for the crate's public API, so the next release is a minor bump. The DynamoDB wire API and the CLI, server and MCP surfaces are unaffected.

Breaking (Rust API): actions::batch_execute_statement::BatchStatementRequest is now #[non_exhaustive]. It is still short of DynamoDB's shape, lacking ConsistentRead and ReturnValuesOnConditionCheckFailure, so it will gain fields again and the attribute is there to stop that breaking anyone twice. Library consumers that construct it must build from Default and assign, or deserialise it. BatchExecuteStatementRequest is deliberately not marked: with ReturnConsumedCapacity on it, that type now matches DynamoDB exactly. This is a source-breaking change for the crate's public API, so the next release is a minor bump. The DynamoDB wire API and the CLI/server/MCP surfaces are unaffected.

Breaking (Rust API): partiql::parser::WhereClause is now #[non_exhaustive] and carries wrote_or, saying whether the clause as written joined anything with OR. The flattened group count no longer answers that, because a NOT over a conjunction becomes a disjunction under De Morgan, so UPDATE ... WHERE pk='x' AND NOT (a=1 AND b=2) used to be refused with a message about an OR the statement did not contain. from_conditions and from_groups are gone with it: both set wrote_or by guessing at it, from_groups from the group count and from_conditions from there being one group, and neither guess survives a NOT. Construct one through from_groups_written, which takes the answer rather than inferring it.

Breaking (Rust API): partiql::executor::statement_target is removed. It resolved a statement's table only to read one item key off it and throw the resolution away, and both batch surfaces now resolve the table once for the whole batch and call statement_target_in per statement instead. A caller that still wants the old one-shot behaviour can get it from ResolvedTable::load followed by statement_target_in. ResolvedTable is the new public type holding that resolution: a table's metadata, its parsed key schema, and the name it was resolved from, so a resolution handed to a call against another table can be spotted rather than obeyed. It is #[non_exhaustive], so build one through load. Source-breaking for the crate's public API; the DynamoDB wire API and the CLI, server and MCP surfaces are unaffected.

Breaking (Rust API): partiql::parser::WhereCondition is now #[non_exhaustive] and carries a NotComparison variant, holding a NOT in front of a comparison rather than flipping the operator. The flip is wrong on a row with no such attribute: a = 'x' is false there, so NOT a = 'x' is true and the row belongs in the result, where a <> 'x' compares a value that is not there and drops it. A downstream match on the enum needs a wildcard arm. The attribute is there because the parser gains a variant every time it learns a predicate, and each one it gained used to break every caller at once.

Breaking (Rust API): partiql::executor::execute_page takes two further arguments beyond the ConsistentRead above: the request's ReturnConsumedCapacity mode, so a write can skip sizing its indexes when nobody asked what it cost, and an optional ResolvedTable, so a batch resolves its table once rather than once per statement. StatementPage gains read_index, naming the index a SELECT was served from, and base_read_units, what an LSI reach-back cost on the base table in read units. The struct is #[non_exhaustive], so the two fields are additive; the argument list is not.

The write paths no longer disagree about the 400KB item-size limit (#187). A number was sized by counting the digit characters of whatever string it held, and storage expands scientific notation, so the same item measured one size as it arrived and another once stored. PutItem checked the limit before that expansion and the other three after it, which is how an item of 8000 attributes holding N "1E125" passed PutItem, was refused by BatchWriteItem, and was then recorded at 552,004 bytes against a 409,600 limit. The recorded size feeds table statistics and the ItemCollectionMetrics estimate. Sizing a number by its significant digits makes the figure survive storage, so where each path checks no longer matters. The surfaces that measure differently on purpose, and the two that were not checking at all, are covered in the behaviour changes above.

ConsumedCapacity under INDEXES charges index writes on the change to what an index stores, not on the item the write leaves behind (#176). Each index used to be charged a unit whenever the finished item belonged to it, which is right for a plain insert and wrong for most else:

• LSI writes are charged. The LocalSecondaryIndexes arm never appeared before, and its units never reached the total.
• An identical overwrite is free, and a write outside a GSI's projection no longer charges that GSI.
• Moving an index key costs two writes; removing one costs a single delete.
• DeleteItem charges an index only when the deleted item was in it.

Units are sized on the projected index entry rather than the base item: an insert or delete costs its own image, an in-place update the larger of the two, and a key move both halves rounded separately. BatchWriteItem inherits all of it. Two of the old figures over-reported rather than under-reported, so any downstream correction for the old numbers needs removing. Captured against eu-west-2.

PutItem, UpdateItem and BatchWriteItem size the table arm on the larger of the item's before and after images, matching DynamoDB. They used to size it on the finished item, so shrinking a 3KB item to 100B reported one unit against DynamoDB's three. Items under 1KB are unaffected, and DeleteItem already sized on the old image.

PutItem sizes the item after normalising it rather than as it arrived. Normalising expands scientific notation, so an item carrying 1E100 grows on the way to storage; the table arm was measuring the request and the stored size was recording it, while the same item read back measured larger. The same write reported one figure as an insert and another as an overwrite, and disagreed with BatchWriteItem, which already sized after normalising.

An overwrite that reorders a set's members is free, as it is on DynamoDB. Sets are unordered, so re-listing the same members leaves an index's stored view alone, but they are held in order internally and the comparison read that as a change, charging every index projecting the set.

Enabling wasm-sqlite alongside the default features now fails with a message that says so. Cargo adds the default features to whatever a manifest lists, so dynoxide-rs = { version = "0.13", features = ["wasm-sqlite"] } also enabled the native backend and the CLI, and the build stopped on three type errors naming neither the feature nor the conflict. The combination was never valid and still is not; what was missing was the diagnosis. Enable the wasm backend with default-features = false.

TransactWriteItems, ExecuteStatement, ExecuteTransaction and BatchExecuteStatement report per-index ConsumedCapacity under INDEXES, where they used to report a Table arm and nothing else (#178). The transactional 2x factor applies to the base table arm alone: an index arm inside a transaction costs what the same write costs outside one. Index units fold into the total, so totals grow on an indexed table under TOTAL as well.

The transactional table arm is sized on the larger of the item's before and after images rather than on the request payload. Delete and ConditionCheck carry a key and no item, so both used to be sized on the key: deleting a 3KB item reported 2 units against DynamoDB's 6. Invisible below 1KB. A ConditionCheck writes nothing and is still charged on the image it read.

A same-token TransactWriteItems or ExecuteTransaction replay is charged against the images the first call was sized on, at 4KB read granularity. It used to recompute from the request, which carries no item for a Delete or a ConditionCheck, so a replayed delete of a 9KB item reported 2 against DynamoDB's 6.

A PartiQL SELECT is served from the index its FROM clause names (#179). SELECT * FROM "table"."index" used to discard the index and scan the base table, so it returned items the index does not contain and a name matching no index quietly succeeded. The qualifier tokenises as three tokens and the table name parser took one, which left the rest for the next clause to parse against, so the WHERE went with it. That single mis-parse cost UPDATE its SET clause and made DELETE report requiring a WHERE clause it plainly had.

The read now follows the index: sparse membership excludes items the index does not hold, and a KEYS_ONLY or INCLUDE projection returns what it projects and no more. Capacity lands on the index arm with the table arm at zero, matching Query and Scan. Continuation tokens carry the base table key, so rows sharing an index key are no longer skipped, and a token is bound to the index that minted it.

Five rejections come with it, each with DynamoDB's own wording: an unknown index name, a FROM path of more than two components, an empty path component, a strongly consistent read of a GSI, and a qualifier on a write statement. A GSI rejects a projection naming an attribute it does not carry; either kind rejects a filter on one, but only when the read is keyed on the index partition key, because an unkeyed read is a scan and a scan matches nothing. Captured against eu-west-2.

A PartiQL predicate on a set, list, map, binary or null attribute compares by value instead of never matching (#186). PartiQL carried its own comparison covering strings, numbers and booleans, and answered every other type from a catch-all returning false for = and true for <>. The same code gates UPDATE and DELETE, so a write conditioned on any of those types could never fire. Sets compare without regard to order, lists in order, maps on their key set. PartiQL now shares the condition-expression engine's comparison rather than carrying a second copy of it. Captured against eu-west-2: the two surfaces agree on every type.

An unterminated quoted name is rejected instead of panicking the parser. SELECT * FROM " sliced a one-character string from index 1, which panics, and the release profile aborts on panic, so a single malformed statement took the process down. Predates the index qualifier, which added a second way to reach it.

BatchStatementRequest carries ConsistentRead (#183) and ReturnValuesOnConditionCheckFailure (#184). Both were absent, so a member setting either was parsed as though it had not.

ConsistentRead is per member and sets the rate that member's read is charged at: a keyed batch SELECT costs 0.5 without it and 1 with it, and a batch mixing the two sums both rates. It does not change which rows come back.

ReturnValuesOnConditionCheckFailure is accepted and inert, which is what DynamoDB does with it. A member whose condition fails returns the same response whether it is ALL_OLD, NONE or absent, and never carries the item; the same option on a TransactWriteItems ConditionCheck does return it, which is what rules out a bad measurement. The field is deserialised so a client setting it meets a field dynoxide knows rather than one it drops. Captured against eu-west-2.

A SELECT inside BatchExecuteStatement must name the table's primary key, and may not name an index. Both shapes were accepted and served; DynamoDB rejects each against that member while the rest of the batch runs, with the same message. An index-qualified batch read is therefore unreachable even when it does name the key.

A batch member whose statement ran and failed echoes its table, where one rejected before it ran does not. ConditionalCheckFailed and DuplicateItem carry TableName and a ValidationError does not, which is what an invalid RETURNING variant is.

Parenthesised grouping and NOT work in a WHERE clause. Both were documented as supported and neither was: the clause parser was a flat OR of ANDs, so even WHERE (a='1') was a parse error, and NOT was recognised only inside NOT EXISTS and NOT BEGINS_WITH. AND binds tighter than OR, and a NOT over a group is applied by De Morgan. A clause whose flattened form exceeds 256 alternatives is rejected as too complex rather than expanded.

An ordering comparison rejects an operand whose type has no ordering. DynamoDB orders S, N and B, and rejects <, <=, >, >= and BETWEEN against anything else before it resolves the table; dynoxide answered no rows. = and <> are unaffected, being defined for every type. Captured against eu-west-2.

An index-qualified SELECT inside ExecuteTransaction is rejected, as it is on DynamoDB, rather than served and charged to the base table arm.

A PartiQL read is charged on the rows it walked rather than the rows it handed back. DynamoDB sizes a read before the WHERE clause and before the projection, so a SELECT matching one row costs what one matching every row costs, and naming one attribute costs what naming all of them costs. Query and Scan already did this; the PartiQL executor summed the rows it was about to return, so any filtered or projected statement under-reported. Captured against eu-west-2.

A statement nested deeper than the parser can walk is rejected rather than taking the process with it. Around 250 nested parentheses in a WHERE clause, or a few thousand leading NOTs, overflowed the stack, and the release profile aborts on panic, so a statement of about a kilobyte was enough to stop the host. Nested list and map literals reached the same end by a second route. Both descents now carry a depth budget and reject past it, as an over-complex clause already was.

A negated comparison keeps the rows its attribute is missing from. NOT a='x' answered on rows holding an a and skipped the rest, because negation flipped the operator and <> is false on a missing path, while NOT CONTAINS wrapped instead and kept them. The two disagreed with each other on the same data. Negation now wraps in every form, so a row the comparison cannot answer for is a row the negation matches.

A SELECT inside BatchExecuteStatement naming a table that does not exist reports the missing table. It reported that the statement must specify a primary key in the where clause, which it had, because the check that reads a member's target cannot tell a missing key from a missing table and only the reads went through it. The same batch reported a missing table correctly for a write and misleadingly for a read.

An LSI read that reaches back to the base table is charged on the bytes each base read moved, not a flat half unit apiece. The flat figure came from one capture of three small rows and holds up to 4KB. Captured again across item sizes: the same three rows at 9KB each cost 4.5 rather than 1.5, and 9 under ConsistentRead. A SELECT * against an INCLUDE index does not reach back at all, and did not before.

Two pieces of repeated work on the write and batch paths are gone. Index writes were sized on every write, and ReturnConsumedCapacity defaults to NONE, where the response builders discard the figure, so a default write projected the old image of every index for nobody. An overwrite against a table with two indexes now builds two projected entries rather than four. Separately, a batch resolved each statement's table metadata and parsed its key schema twice, and a failing statement a third time; both are per-table facts, so a batch resolves each table once however many statements it carries. A 25-statement batch goes from 51 metadata loads and 51 key schema parses to one of each, which matters most on the wasm backend, where every load crosses the bridge to a JS worker and nothing caches the result.

An LSI serves a projection naming an attribute it does not carry by reading the base item, which is what DynamoDB does and a GSI cannot. dynoxide returned rows of empty objects. The base reads land on the table arm at read granularity apiece, so three rows served this way report total 2, table 1.5, lsi 0.5.