MaxCompute provides atomicity, consistency, isolation, and durability (ACID) guarantees for concurrent write jobs. The specific guarantees depend on whether you are using standard tables or transactional tables.
Key concepts
| Term | Definition |
|---|---|
| Operation | A single job submitted in MaxCompute. |
| Data object | An object that stores data, such as a non-partitioned table or a partition. |
| INTO job | An SQL job that contains the INTO keyword, such as INSERT INTO or DYNAMIC INSERT INTO. |
| OVERWRITE job | An SQL job that contains the OVERWRITE keyword, such as INSERT OVERWRITE or DYNAMIC INSERT OVERWRITE. |
| Data upload by using Tunnel | An INTO or OVERWRITE job. |
ACID guarantees
Atomicity
Standard tables
If multiple jobs conflict, MaxCompute ensures that only one succeeds.
Atomicity is guaranteed for CREATE, OVERWRITE, and DROP operations on a single table or partition.
Atomicity is not guaranteed for cross-table operations such as MULTI-INSERT.
Atomicity may also not be guaranteed in the following edge cases:
A DYNAMIC INSERT OVERWRITE operation on more than 10,000 partitions.
An INTO operation. If a transaction rollback occurs, data cleansing may fail. The original data is not lost, but residual data from the failed job may remain.
Transactional tables (additional guarantee)
Atomicity is guaranteed for UPDATE, DELETE, and small file MERGE operations on a non-partitioned table or a partition. For example, if two UPDATE operations run on the same partition simultaneously, exactly one succeeds — partial execution and dual success are both impossible.
Consistency
Standard tables
Consistency is guaranteed for OVERWRITE jobs.
If an INTO job fails due to a conflict, data from the failed job may remain.
Transactional tables (additional guarantee)
If an INTO job fails due to a conflict, data from the failed job does not remain.
Isolation
Standard tables
For non-INTO operations, MaxCompute ensures that read operations are submitted.
For INTO operations, some read operations may not be submitted.
Transactional tables (additional guarantee)
INTO operations: MaxCompute ensures that read operations are submitted.
Durability
MaxCompute guarantees data durability for all table types. After an operation completes, the modified data is permanently persisted and is not lost even if a system failure occurs.
How conflicts are resolved
When jobs run concurrently on the same destination table or partition, a conflict may occur. The resolution rule is:
The job that finishes first succeeds. The job that finishes later may fail.
Example
The following scenario illustrates two UPDATE operations on the same partition:
t0: job_A starts (UPDATE on partition p1)
t1: job_B starts (UPDATE on partition p1)
t2: job_A commits — succeeds, partition p1 is updated
t3: job_B attempts to commit — detects that p1 changed since job_B started reading → reports a conflict errorJob B reports an error because the data it read is now stale. Job A's result is preserved.
Conflict outcome matrix
The following table shows the outcomes when two jobs are submitted at the same time on the same non-partitioned table or partition. "Earlier" and "later" refer to which job finishes first.
| Job ending earlier | INSERT OVERWRITE or TRUNCATE ending later | INSERT INTO ending later | UPDATE or DELETE ending later | Small file MERGE ending later |
|---|---|---|---|---|
| INSERT OVERWRITE or TRUNCATE | Both succeed. The later job's data overwrites the earlier job's data. | Both succeed. The later INSERT INTO appends its data to the earlier job's result. | The later UPDATE or DELETE reports an error. | The later small file MERGE reports an error. |
| INSERT INTO | Both succeed. The later OVERWRITE data overwrites the earlier INSERT INTO result. | Both succeed. The later INSERT INTO appends its data to the earlier result. | The later UPDATE or DELETE reports an error. | The later small file MERGE reports an error. |
| UPDATE or DELETE | Both succeed. The later OVERWRITE data overwrites the earlier UPDATE or DELETE result. | Both succeed. The later INSERT INTO appends its data to the earlier result. | The later UPDATE or DELETE reports an error. | The later small file MERGE reports an error. |
| Small file MERGE | Both succeed. The later OVERWRITE data overwrites the earlier MERGE result. | Both succeed. The later INSERT INTO appends its data to the earlier result. | The later UPDATE or DELETE reports an error. | The later small file MERGE reports an error. |
Summary rules
INSERT operations (OVERWRITE and INTO) never conflict with each other. Two INSERT jobs always both succeed, regardless of order.
UPDATE, DELETE, and small file MERGE fail when the target data has changed. If the destination non-partitioned table or partition was modified by an earlier job, the later UPDATE, DELETE, or small file MERGE reports a conflict error.
In edge cases where multiple jobs run concurrently while metadata is being updated, jobs may also report conflict errors caused by metadata changes.