DynamoDB TransactionConflictException

TL;DR — Another transaction is already operating on the same item as your request, so DynamoDB rejected yours to preserve isolation. It's transient contention, not a bug in your data — retry with exponential backoff, keep transactions small, and cut down concurrent writes to the same hot item.

What it means

TransactionConflictException: Transaction is ongoing for the item

DynamoDB serializes conflicting writes against in-flight transactions. You hit this exception when a plain PutItem, UpdateItem, or DeleteItem collides with an in-flight TransactWriteItems that includes the same item. Rather than block, DynamoDB rejects the single-item write with TransactionConflictException (HTTP 400). It is retryable — the conflict clears once the other transaction commits or aborts.

Note the distinction from TransactionCanceledException: when the losing request is itself a TransactWriteItems or TransactGetItems, DynamoDB cancels that whole transaction instead — you get a cancellation whose CancellationReasons carry TransactionConflict as the per-item reason code, not this exception.

Why it happens

  • Concurrent writes to the same item — a plain PutItem/UpdateItem overlaps an in-flight TransactWriteItems touching that item.
  • Two transactions sharing an item — two TransactWriteItems requests include the same key at the same time; one wins, the other is cancelled with a TransactionConflict reason code (surfaced as TransactionCanceledException).
  • A hot item under heavy concurrent updates — e.g. a shared counter or a single aggregate row every request updates.
  • Long or large transactions holding items long enough to overlap other writers.
  • A retry storm — retries without backoff pile more concurrent attempts onto the same contended item.

How to fix it

  1. Retry with exponential backoff + jitter. This is the primary fix — the conflict is transient and clears when the other transaction settles. Keep jitter so retries don't resynchronize into another collision.
  2. Keep transactions small and short — fewer items per TransactWriteItems means shorter holds and less overlap.
  3. Reduce contention on hot items — shard a hot counter across multiple items and aggregate, or use an atomic counter with a plain UpdateItem (ADD) instead of a transaction when you don't need all-or-nothing semantics.
  4. Don't mix a transaction and a plain write on the same item concurrently if you can avoid it — route both through the same path.
  5. Monitor the TransactionConflict CloudWatch metric to see whether contention is rising and where.

Inspect in DynoTable

When the concurrent writer is you, batch manual edits through staging (⌘S) — DynoTable commits them as one reviewed write instead of a stream of overlapping single-item updates. Open contended items with ⌘K and inspect live state before retrying.

Size transactional traffic with the pricing calculator. Switch profiles with ⌘P; Test Connection on Settings → Profiles. See Connect to AWS and Install.

Sources

FAQ

How do I fix TransactionConflictException in DynamoDB? Retry the request with exponential backoff and jitter — the conflict is transient contention with another in-flight transaction on the same item. Also keep transactions small, shard hot items, and avoid running a transaction and a plain write against the same item concurrently.

Is TransactionConflictException the same as TransactionCanceledException? No. TransactionConflictException means another transaction is currently operating on the item. TransactionCanceledException means a whole transaction was rolled back; its CancellationReasons explain why, and a transaction conflict can be one of those reasons.

References

Last verified 2026-07-13 against the official AWS documentation linked above.

Work with DynamoDB without the Console

A fast DynamoDB desktop client that runs the real SQL DynamoDB can’t — JOINs, GROUP BY, aggregates — with visual editing and an AI agent on your own Bedrock keys.

Free 30-day trial, no credit card — then the Free plan with no time limit.