Google Cloud eases Spanner DML transaction limits

Google Cloud has changed transaction limits in Spanner for Data Manipulation Language statements. The update removes the overall transaction-level mutation cap for DML while keeping the 80,000 limit for each individual statement.

The change affects how developers structure larger transactions in Spanner, Google Cloud's relational database service for operational workloads.

Previously, Spanner limited a transaction to 80,000 mutation modifications from DML. That total was calculated from the number of rows and columns changed, along with dependent index updates.

Now, the 80,000 threshold applies to each DML statement rather than the full transaction. A transaction can include any number of DML statements, such as INSERT, UPDATE, or DELETE, as long as each one stays below the 80,000-modification ceiling.

Developers can now group multiple update steps into a single transaction without splitting the work only to stay within a cumulative mutation count. The change applies to applications using standard DML syntax and does not require updates to existing Spanner client libraries or application code.

How it works

The revised limit applies only to DML statements. Each executeUpdate-style statement is checked independently against the 80,000-modification threshold.

A different rule still applies to the Mutation API. When developers use client library methods such as insert() or update() and send mutations during a commit call, the 80,000 limit still applies to the full set of mutations in that call.

This distinction matters for teams that mix database access patterns. DML statements now have more flexibility within a transaction, but applications that rely on the Mutation API still face the older transaction-wide ceiling for a commit operation.

Spanner counts mutation modifications by the complexity of a change, not a simple row total. The total can include modified cells, primary keys, and updates to secondary indexes, so apparently small changes can produce larger mutation counts depending on schema design.

Operational impact

The update is aimed at transactional workloads that require a sequence of linked writes to succeed or fail together. Google Cloud pointed to use cases such as fraud checks during a multi-step online checkout, where several data changes may need to be committed consistently before the next request can read the result.

In practice, teams can align transaction boundaries more closely with business logic. Instead of breaking a process into several smaller transactions because of cumulative DML limits, they can keep related steps together if each individual statement remains under the threshold.

There are still trade-offs. Larger, longer-running transactions hold locks for more time, which can increase contention and raise the chance of aborts.

Google Cloud advises developers to keep transactions concise to reduce resource contention. Users should also monitor CommitStats, where mutation_count for a committed transaction shows the full mutation total across all DML statements and commit calls in that transaction.

Limits remain

Not all transaction constraints have been removed. Any single DML statement that generates more than 80,000 modification units will still fail with the same error returned under the earlier model.

Other limits also remain, including the maximum transaction size in bytes. The change broadens one aspect of transaction design, but it does not remove the need to plan around Spanner's broader quotas.

Google Cloud also outlined alternatives for operations that still exceed the per-statement limit. If a single bulk update is too large, developers may need to use Partitioned DML or paginate through keys to break the work into smaller units.

Example use

Google Cloud provided a Java example showing several executeUpdate calls inside one read-write transaction. In that example, separate UPDATE and INSERT statements are executed one after another, with each statement assessed independently against the 80,000-modification threshold.

The example illustrates the main practical shift. Previously, the combined effect of those statements could push a transaction over the limit even if no single statement was too large. Under the new model, the same pattern can proceed in one transaction as long as each step stays within the per-statement boundary.

The update reflects a narrower but significant adjustment to Spanner's transaction model for application teams managing evolving workloads. As data models expand and services add more business logic, multi-step transactional updates can grow even when each individual operation remains modest.

Users can still monitor the total modifications for a committed transaction through mutation_count in CommitStats, even though DML statements no longer contribute to an overall transaction-level mutation limit.