Google Cloud announced on 9 September 2026 that Spanner now evaluates the 80,000 mutation-mod limit separately for each DML statement. Existing client libraries work with the change without an application update. Teams can therefore group more INSERT, UPDATE and DELETE statements within one ACID transaction when the business operation genuinely requires an all-or-nothing result.
What happened: the DML limit moved from transaction to statement
Previously, mutation mods generated by DML statements accumulated across a transaction. A growing workflow could reach the 80,000 limit even when no individual statement was especially large, forcing developers to split work or redesign the operation.
The limit now applies independently to each DML statement. A transaction may contain any number of DML statements, provided every statement generates fewer than 80,000 mutation mods and the transaction remains within Spanner's other limits, including maximum transaction size in bytes.
The change is specific to DML. The Mutation API still evaluates the 80,000 limit across the mutations supplied in a commit. A single oversized DML statement also remains subject to the existing limit and may still need Partitioned DML or key-based pagination.
Why it matters: logical atomicity is easier, operational pressure is not
Applications can now keep related changes inside the same business transaction instead of introducing artificial commit boundaries solely to satisfy the cumulative limit. That can simplify correctness for workflows such as order processing, entitlement changes or fraud decisions where partial completion is unacceptable.
More headroom does not make a larger transaction free. Google warns that larger and longer-running transactions hold locks for longer, increasing the chance of contention and transaction aborts. Retried transactions can then amplify load and extend user-visible latency, especially when multiple workers compete for the same keys.
The release therefore changes a hard ceiling into a design choice. The useful question is no longer only whether a transaction fits. Teams must decide whether its atomic scope is worth the lock duration, retry volume and failure blast radius under production concurrency.
The practical implication: prove the new atomic boundary under contention
Start with the business invariant: identify exactly which writes must succeed or fail together. Keep unrelated maintenance, enrichment and downstream work outside that boundary. Avoid combining statements merely because the platform now allows it.
Load-test the revised transaction against realistic hot keys and concurrency. Track total mutation_count through CommitStats, transaction duration, lock wait, abort rate, retry attempts, p95 and p99 latency, and the additional compute caused by retries. Test idempotency and confirm the client retry policy cannot duplicate external side effects.
Roll out gradually with a rollback threshold. Compare the larger transaction with the current implementation for correctness, throughput and tail latency. If a single statement remains too large, use the documented alternatives rather than spreading one bulk operation across an increasingly expensive interactive transaction.
Key takeaways
Use the expanded DML headroom only where one atomic business outcome requires it; keep unrelated work outside the transaction.
Measure mutation count, transaction duration, lock contention, aborts, retries and tail latency with representative concurrency.
Keep retry logic idempotent, define rollback thresholds and remember that Mutation API and maximum transaction-size limits have not changed.
Sources
This article is original analysis written by IT Web Builder. The reporting and product details below were used as references and are credited to their publishers.
Google Cloud Blog — Spanner: Removing cumulative mutation limits for DML transactionsPublished 9 September 2026. Primary announcement for the per-statement DML limit, compatibility, locking and abort considerations, Mutation API distinction and CommitStats guidance.↗Google Cloud Documentation — Quotas and limits for SpannerOfficial reference for transaction, commit and mutation constraints that remain relevant when designing larger operations.↗Google Cloud Documentation — Read-write transactionsOfficial guidance on locking, transaction retries and application behaviour for read-write transactions.↗IT Web Builder publishes original summaries and practical commentary. We do not reproduce source articles. Product claims and announcements are linked to their original publishers so readers can verify the details.