Explain the execution flow of a partitioned DML statement in Spanner?

Partitioned DML is designed for bulk updates or deletes that would be impractical, or impossible, inside a single transaction, so instead of one atomic operation it decomposes the statement into many independent pieces.

Spanner first analyzes the statement's key range and splits it into partitions roughly aligned with existing table splits. Each partition is then executed as its own small, independent read-write transaction that commits on its own, rather than all partitions committing together atomically. This means a partitioned DML statement is not all-or-nothing: if it's interrupted partway through, some partitions will have committed and others won't, so it's designed to be idempotent and safely re-runnable rather than treated like a single ACID operation. The trade-off is deliberate - by giving up whole-statement atomicity, Spanner can update or delete rows across an entire large table without a single long-running transaction holding excessive locks or exceeding transaction size limits.