# 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](/docs/lakehouse/sql-engine.md) against an [Altertable catalog](/docs/lakehouse.md) you own.

## Basic transaction syntax

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

```sql
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:

```sql
ROLLBACK;
```

`ABORT` has the same behavior as `ROLLBACK`.

## Snapshots

Each committed transaction — a `BEGIN` … `COMMIT` block — creates one catalog snapshot. Snapshots power [time travel](/docs/lakehouse/features/time-travel.md) and the [data change feed](/docs/lakehouse/features/data-change-feed.md).

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](/docs/lakehouse/features/time-travel.md)**: Query historical snapshots and configure retention
- **[Data Change Feed](/docs/lakehouse/features/data-change-feed.md)**: Read inserts, updates, and deletes between snapshots
- **[SQL Engine](/docs/lakehouse/sql-engine.md)**: DuckDB dialect and federated queries