Skip to content

Saving Data

SaveChangesAsync reads the EF Core change tracker, compiles each pending entity state into a PartiQL statement, and sends the writes to DynamoDB — with optional transaction wrapping, configurable overflow behavior, and optimistic concurrency support.

Async only

The DynamoDB SDK does not expose synchronous write APIs. SaveChanges always throws NotSupportedException. Always use SaveChangesAsync.

How It Works

When you call SaveChangesAsync, the provider runs a two-stage pipeline:

  1. Compile — DynamoSaveChangesPlanner inspects every tracked entity and compiles its state into a PartiQL statement. Statements are validated before any network call is made.
  2. Execute — DynamoWriteExecutor sends the compiled statements to DynamoDB using ExecuteStatement (single operation), ExecuteTransaction (multiple operations, atomic), or BatchExecuteStatement (multiple operations, non-atomic) depending on configuration.

The mapping from EF Core entity state to DynamoDB write operation:

EF Entity State PartiQL Statement
Added INSERT INTO "Table" VALUE {'pk': ?, '$type': ?, ...}
Modified UPDATE "Table" SET "prop" = ? REMOVE "other" WHERE "pk" = ?
Deleted DELETE FROM "Table" WHERE "pk" = ?

Only modified properties appear in UPDATE statements — unchanged properties are omitted entirely. Setting a property to null removes the attribute from DynamoDB (REMOVE), not sets it to { NULL: true }.

In This Section

  • Add, Update, and Delete — How each entity state translates to a PartiQL statement, what the generated SQL looks like, how complex properties are handled in updates, and the 8,192-byte statement size limit.
  • Transactions — Auto-transaction wrapping via ExecuteTransaction, the 100-item limit, overflow behavior (throw vs. chunking), and non-transactional batch writes.
  • Optimistic Concurrency — Configuring concurrency tokens, manual token updates, conflict detection, and handling DbUpdateConcurrencyException.

See also