Databricks announced on 16 October 2026 that multi-statement transactions are generally available for Unity Catalog managed Delta Lake and Apache Iceberg tables. The rollout was staged. The feature entered public preview in March, and the July 2026 release notes marked transactions on managed Delta tables as generally available while Iceberg tables stayed in private preview.
Cloud warehouses such as Snowflake and BigQuery already support multi-statement transactions. Open table formats on their own commit one table at a time, and the reason lies in how they record changes.
What a multi-statement transaction does
A multi-statement transaction groups several SQL statements, often across several tables, so that they commit together or not at all. A nightly load might insert into a fact table, update a dimension table and write an audit row. Without a transaction, if the third statement fails, the first two have already landed, and someone has to write logic to detect and repair the partial state.
Databricks' announcement quotes Fivetran describing that problem. Its history mode writes two rows per source change, closing out the old version of a record and inserting the new one. Fivetran said committing both as one transaction let it remove "an entire class of consistency-repair code." That is a vendor-published customer quote, not an independent measurement.
Why table formats commit one table at a time
Delta Lake and Iceberg give ACID guarantees per table. Databricks' documentation on ACID guarantees says that by default each SQL statement runs as its own atomic transaction against one table, and that a table's current state is the set of data files marked valid in its transaction log. Concurrency control is optimistic: writers take no locks, and conflicts are checked at commit time.
The Iceberg table spec follows the same principle. A writer prepares a new metadata file and commits by swapping the table's metadata pointer from the base version to the new one in an atomic operation. If the snapshot the writer started from is no longer current, it must retry the update against the new current version.
Each table has its own log or pointer, so nothing at the file level ties a commit on one table to a commit on another. Atomicity across tables needs a coordinator that sits above the tables. In practice, that coordinator is the catalog.
How the main platforms differ
Databricks. Every table written inside a transaction must be a Unity Catalog managed table with catalog commits enabled, according to the transactions documentation, which makes Unity Catalog the commit coordinator. A transaction can read from or write to up to 100 tables. There are two modes. Non-interactive transactions wrap statements in a BEGIN ATOMIC block closed by END and support row-level conflict detection when row-level concurrency is enabled on the target tables. Interactive transactions open with BEGIN TRANSACTION and close with COMMIT. They require a SQL warehouse and use more conservative checks that can conflict at the table level, except for inserts that do not read from the target table. Inside a transaction, each table is read from a snapshot taken at first access, and writes default to write-serializable isolation.
Snowflake. Snowflake supports explicit transactions, and its transactions reference says read committed is the only isolation level currently supported for tables. A DDL statement issued while a transaction is open implicitly commits that transaction, then runs as a separate transaction of its own. Snowflake's page on Iceberg tables notes that Iceberg itself supports serializable or snapshot isolation, while Snowflake applies read committed.
BigQuery. Google's multi-statement transactions can modify tables that span multiple datasets or projects, and reads within a transaction return a consistent snapshot of the tables it references. If a transaction is mutating rows in a table, other transactions that try to mutate rows in the same table are cancelled, DML statements outside a transaction are queued, and reads and appends can continue alongside.
Open Iceberg catalogs. The Iceberg REST catalog OpenAPI specification defines an endpoint, POST /v1/{prefix}/transactions/commit, to "commit updates to multiple tables in an atomic operation." Catalog servers can advertise which endpoints they support. A September 2026 article from Dremio, a lakehouse vendor, notes that a catalog server may not expose this endpoint, and that the engine must also submit a single commit request and handle conflicts and retries correctly.
What to check before moving warehouse jobs
The isolation level, by name. Read committed, snapshot and serializable isolation behave differently for a job that reads a table and then writes back to it. Under read committed, a second read of the same table inside one transaction can return rows another session committed in between. Under snapshot isolation, it does not see commits made by other sessions after the snapshot was taken.
Conflict granularity and resolution. Row-level detection lets concurrent jobs change different rows of the same table. Under table-level detection, two jobs writing the same table can conflict even when they touch different rows, and one of them fails. Platforms also differ on what happens to the transaction that loses. BigQuery cancels it. Databricks rolls a non-interactive transaction back automatically, but in interactive mode requires an explicit ROLLBACK to clear the transaction state before another transaction can begin.
Which tables qualify. On Databricks, transactions can write only to managed tables with catalog commits enabled, so external tables are out of scope as write targets. The external access documentation says external Delta clients can write to managed tables only when catalog commits are enabled, with Apache Spark as the supported client and other engines in beta.
What external readers see. An atomic commit in one catalog does not guarantee that every reader sees it atomically. Dremio's article notes that a server may apply multi-table updates atomically but still let concurrent readers observe intermediate states, depending on how it exposes snapshot visibility.
What commonly goes wrong
DDL inside a transaction. Snowflake commits the open transaction when a DDL statement appears, so a later ROLLBACK cannot undo the statements that ran before it. Databricks does not support DDL such as CREATE TABLE, ALTER TABLE or DROP TABLE inside a transaction at all, and its documentation says to run those statements outside. A script ported from one platform to the other will not behave the same way.
Long interactive sessions. Under optimistic concurrency, the longer a transaction stays open, the more likely another writer commits first and forces a conflict. Databricks advises keeping transactions short and building in retries. It rolls back interactive transactions after 10 minutes of inactivity and any transaction after 48 hours.
Reading "REST catalog support" as multi-table atomicity. A catalog can serve Iceberg tables over the REST protocol without exposing the multi-table commit endpoint, and an engine can use a REST catalog without calling it. The useful question for a vendor is whether its catalog and every engine that will write to it implement that endpoint, and at which isolation level.
Sources
- Databricks. "Transactions are Generally Available, advancing warehousing on the Lakehouse." 16 October 2026. https://www.databricks.com/blog/transactions-are-generally-available-advancing-warehousing-lakehouse
- Databricks. "Transactions on the Open Lakehouse Unlock Mission-Critical Warehousing Workloads." 4 March 2026. https://www.databricks.com/blog/transactions-open-lakehouse-unlock-mission-critical-warehousing-workloads
- Databricks. "July 2026 release notes." 22 July 2026 entry. https://docs.databricks.com/aws/en/release-notes/product/2026/july
- Databricks. "What are ACID guarantees on Databricks?" Documentation, updated 19 October 2026. https://docs.databricks.com/aws/en/lakehouse/acid
- Databricks. "Transactions." Documentation, updated 19 October 2026. https://docs.databricks.com/aws/en/transactions/
- Databricks. "Catalog commits." Documentation. https://docs.databricks.com/aws/en/tables/features/catalog-commits
- Databricks. "Access Databricks tables from Delta clients." Documentation, updated 15 October 2026. https://docs.databricks.com/aws/en/external-access/unity-rest
- Apache Iceberg. "Iceberg Table Spec," Optimistic Concurrency section. https://iceberg.apache.org/spec/
- Apache Iceberg. REST catalog OpenAPI specification. https://github.com/apache/iceberg/blob/main/open-api/rest-catalog-open-api.yaml
- Snowflake. "Transactions." SQL reference. https://docs.snowflake.com/en/sql-reference/transactions
- Snowflake. "Transactions and Apache Iceberg tables." Documentation. https://docs.snowflake.com/en/user-guide/tables-iceberg-transactions
- Google Cloud. "Multi-statement transactions." BigQuery documentation. https://docs.cloud.google.com/bigquery/docs/transactions
- Dremio. "Multi-Table Transactions with Iceberg REST Catalogs and Apache Polaris." 25 September 2026. https://www.dremio.com/blog/multi-table-transactions-with-iceberg-rest-catalogs-and-apache-polaris