What causes TRANSACTION_DEADLOCK?

Two transactions each hold a lock on one table and try to acquire a lock on the other table simultaneously. Long-running DML transactions holding locks while other processes attempt to write to the same tables. Multiple ETL jobs modifying the same staging tables in overlapping time windows. A transaction left open (not committed or rolled back) blocking other transactions indefinitely. Stored procedures that lock multiple tables in inconsistent order across executions

How do I fix TRANSACTION_DEADLOCK?

Retry the aborted transaction — Snowflake's deadlock resolution aborts the transaction with the lowest cost to roll back. Implement automatic retry logic in the application layer for deadlock errors. Review transaction scope: minimize the number of tables touched in a single transaction. Enforce consistent lock acquisition order across all processes that access the same set of tables. Check for orphaned open transactions: SELECT * FROM TABLE(INFORMATION_SCHEMA.TRANSACTION_HISTORY()) WHERE STATUS = 'RUNNING'. Use COMMIT or ROLLBACK promptly — do not leave transactions open between user interactions

High severityexecution

Power BI Refresh Error:
TRANSACTION_DEADLOCK

What does this error mean?

Two or more concurrent transactions are waiting for each other to release locks, creating a circular dependency. Snowflake detects the deadlock and aborts one of the transactions.

Common causes

1Two transactions each hold a lock on one table and try to acquire a lock on the other table simultaneously
2Long-running DML transactions holding locks while other processes attempt to write to the same tables
3Multiple ETL jobs modifying the same staging tables in overlapping time windows
4A transaction left open (not committed or rolled back) blocking other transactions indefinitely
5Stored procedures that lock multiple tables in inconsistent order across executions

How to fix it

1Retry the aborted transaction — Snowflake's deadlock resolution aborts the transaction with the lowest cost to roll back
2Implement automatic retry logic in the application layer for deadlock errors
3Review transaction scope: minimize the number of tables touched in a single transaction
4Enforce consistent lock acquisition order across all processes that access the same set of tables
5Check for orphaned open transactions: SELECT * FROM TABLE(INFORMATION_SCHEMA.TRANSACTION_HISTORY()) WHERE STATUS = 'RUNNING'
6Use COMMIT or ROLLBACK promptly — do not leave transactions open between user interactions

Frequently asked questions

Is Snowflake ACID compliant?

Yes — Snowflake provides ACID guarantees for single-statement DML and explicitly opened multi-statement transactions. Deadlocks are an inherent risk of multi-statement transactions that span multiple tables.

Does Snowflake use row-level or table-level locking?

Snowflake uses DML statement-level locks on micropartitions, not row-level locks. Concurrent reads never block writes (MVCC). Deadlocks are possible when multiple write transactions modify overlapping sets of micropartitions.