Transactions

Altertable catalogs provide full ACID support with snapshot isolation for all reads and writes. Every operation — including DDL statements such as CREATE TABLE or ALTER TABLE — runs inside a transaction with all-or-nothing semantics. A transaction can compose multiple changes that succeed or fail together.

Run the statements below through Altertable's SQL engine against an Altertable catalog you own.

Basic transaction syntax

Start a transaction, apply changes, then commit or roll back:

Copy
1
2
3
4
5
6
7
8
9
10
BEGIN TRANSACTION;

INSERT INTO my_catalog.main.purchase_orders (po_id, status, amount)
VALUES ('PO-8821', 'draft', 4200.00);

UPDATE my_catalog.main.purchase_orders
SET status = 'approved'
WHERE po_id = 'PO-8821';

COMMIT;

To discard uncommitted work:

Copy
ROLLBACK;

ABORT has the same behavior as ROLLBACK.

Snapshots

Each committed transaction — a BEGIN … COMMIT block — creates one catalog snapshot. Snapshots power time travel and the data change feed.

Use transactions when you need a consistent point-in-time view across multiple statements, or when a batch of writes must land atomically.

Concurrent writes

When multiple transactions modify the same table concurrently, Altertable applies a default retry mechanism for conflicting writes.

For long-running batches, keep transactions as short as practical to reduce contention and snapshot buildup.

Learn more

• Time Travel: Query historical snapshots and configure retention
• Data Change Feed: Read inserts, updates, and deletes between snapshots
• SQL Engine: DuckDB dialect and federated queries