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/DELETE update expressions without sending whole items.
  • Compose key conditions that keep a Query selective at the index level.
  • Alias reserved attribute names and bind values without JSON escaping errors.

Reading order

  1. Condition expressions — atomic predicates on PutItem, UpdateItem, and DeleteItem; optimistic locking.
  2. Update expressions — partial updates without read-modify-write round trips.
  3. Key condition expressions — what a Query can filter before capacity is charged.
  4. Projection expressions — return only the attributes your UI needs.
  5. Expression names and values#status and :threshold mechanics shared by every expression type.
0 of 6 readQuiz

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.