Expressions

You ship an update 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.

This section covers five parts of it: #name / :value placeholders bind names and values in every expression, condition expressions gate writes, update expressions change one item in place, key conditions decide what a Query reads, and projection expressions trim what comes back.

Filter expressions, which discard items after the read, are covered in filtering strategies.

What this section teaches you to do

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

Expression names and values: #status and :threshold mechanics shared by every expression type.
Condition expressions: atomic predicates on PutItem, UpdateItem, and DeleteItem; optimistic locking.
Update expressions: partial updates without read-modify-write round trips.
Key condition expressions: what a Query reads, and so what it bills.
Projection expressions: return only the attributes your UI needs.

0 of 6 readQuiz

DynamoDB Expression Attribute Names and Values

How DynamoDB expression attribute names (#name) and values (:value) work, why reserved words like status and name break your query, and how to fix it.

Intermediate5 min read

DynamoDB Condition Expressions: Make a Write Conditional

DynamoDB condition expressions enforce an invariant inside a single write. How they replace read-then-update, and why a rejected write still consumes write capacity.

Intermediate7 min read

DynamoDB Update Expressions: SET, REMOVE, ADD, DELETE

How DynamoDB update expressions work (SET, ADD, REMOVE, DELETE) and which one to reach for, with a CMS article worked example.

Intermediate6 min read

DynamoDB Key Condition Expressions

How DynamoDB key condition expressions work, the operators allowed on the sort key, begins_with vs BETWEEN, and why a filter is not a substitute.

Intermediate6 min read

DynamoDB Projection Expressions

DynamoDB projection expressions return only the attributes you name. Why they cut payload but not read cost, and what to use instead to cut read cost.

Beginner6 min read

Knowledge checkTake the quiz

Check what you’ve learned in this section.

version = :v on an update turns a lost race into a ConditionalCheckFailedException, which you handle by re-reading the item and retrying with the new version.

status is a reserved word; a bare status = :s fails to parse until you alias it to #s. The reserved-words checker flags all 573 AWS reserved words and suggests aliases.

The partition key in a key condition takes only =; the sort key takes =, <, <=, >, >=, BETWEEN or begins_with. A non-key attribute can't appear in a key condition at all.

If you filter on a non-key attribute as a regular access pattern, create a GSI keyed on it and query that; make it sparse if only some items carry the attribute.

A filter expression on a Scan still reads, and bills, the whole table; the expression only hides rows in the response. Move the predicate into a key condition on the table or a GSI (Query vs Scan).

Projection expressions trim response payloads on reads (GetItem, Query, Scan, BatchGetItem), which matters when items carry large blobs you never show in the grid. To trim what a write returns, use ReturnValues UPDATED_NEW.

Update expressions bundle SET, REMOVE, ADD, and DELETE clauses in one atomic UpdateItem.

Tools

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 review its per-attribute diff before commit; the commit is a conditional write, so a concurrent change surfaces as a conflict instead of being overwritten. Paid plans unlock staging and commits.

Free read-only access still lets you build key conditions and filters in the visual filter builder, pick columns with PartiQL SELECT, and export the query as code.