Expressions
You ship a conditional write without a condition expression, two workers update the same item, and the last writer wins with no error. DynamoDB will not infer SQL-style row locks — you spell out the predicate in an expression or accept the race.
Expressions are the small language behind every selective read and safe write:
key conditions narrow a Query, filter expressions discard after the read,
condition expressions gate atomic updates, and projection expressions trim
payload size. Reserved words, #name placeholders, and :value bindings trip
every team once; this section separates the four families so you reach for the
right one.
What you can do after
- Write a condition expression that rejects stale writes instead of overwriting them.
- Build
SET/REMOVE/ADD/DELETEupdate expressions without sending whole items. - Compose key conditions that keep a
Queryselective at the index level. - Alias reserved attribute names and bind values without JSON escaping errors.
Reading order
- Condition expressions — atomic
predicates on
PutItem,UpdateItem, andDeleteItem; optimistic locking. - Update expressions — partial updates without read-modify-write round trips.
- Key condition expressions — what
a
Querycan filter before capacity is charged. - Projection expressions — return only the attributes your UI needs.
- Expression names and values —
#statusand:thresholdmechanics shared by every expression type.
attribute_exists(version) AND version = :v on an update turns a lost race into a
ConditionalCheckFailedException you can retry. A filter expression on a Scan
still reads the whole table — the expression only hides rows in the response.
status is a reserved word; bare status = :s fails parse until you alias it to
#s. The reserved-words checker flags all
573 AWS reserved words and suggests aliases.
Key condition expressions only accept a narrow operator set on partition and sort
keys — equality, begins_with, between, and comparisons on the sort key when the
partition key is fully specified. You cannot filter on arbitrary attributes at the
key-condition layer; that is what filter expressions do after capacity is charged.
Projection expressions trim response payloads on reads and on ReturnValues after
writes, which matters when items carry large blobs you never show in the grid.
Update expressions bundle multiple SET, REMOVE, ADD, and DELETE clauses in
one atomic UpdateItem. DynoTable's item editor generates these clauses when you
change fields in staging so you see the exact expression before commit.
In DynoTable
Build expressions in the browser with the free Expression Builder — pick an operation, add clauses, and export SDK/CLI/boto3/PartiQL snippets without hand-escaping JSON.
In DynoTable, stage an item edit and watch update expressions in the
diff before commit. Paid plans unlock staging and commits; free read-only access still
lets you compose and export queries with projection and filter expressions via the
filter builder and PartiQL SELECT.
Download DynoTable to run these expressions against live items.