- Documentation
- Specification
- Introduction
- Data Types
- Queries
- Tables
- Overview
- column
- column_mapping
- name_mapping
- column_tag
- data_file
- delete_file
- file_column_stats
- file_partition_value
- files_scheduled_for_deletion
- inlined_data_tables
- metadata
- partition_column
- partition_info
- schema
- schema_versions
- snapshot
- snapshot_changes
- table
- table_column_stats
- table_stats
- tag
- view
- DuckDB Extension
- Introduction
- Usage
- Connecting
- Choosing a Catalog Database
- Choosing Storage
- Snapshots
- Schema Evolution
- Time Travel
- Upserting
- Configuration
- Paths
- Maintenance
- Recommended Maintenance
- Merge Files
- Expire Snapshots
- Cleanup of Files
- Rewrite Files with Deletes
- Checkpoint
- Advanced Features
- Constraints
- Conflict Resolution
- Data Change Feed
- Data Inlining
- Encryption
- Partitioning
- Transactions
- Row Lineage
- Views
- Comments
- Metadata
- Migrations
- Guides
- Unsupported Features
- FAQ
DuckLake has full support for ACID and offers snapshot isolation for all interactions with the database.
All operations, including DDL statements such as CREATE TABLE or ALTER TABLE, have full transactional support.
Transactions have all-or-nothing semantics and can be composed of multiple changes that are made to the database.
The extension also provides some syntax to be able to manage transactions. This is explained in the DuckDB documentation. Basically it comes down to this:
BEGIN TRANSACTION;
-- Some operation
-- Some other operation
COMMIT;
-- Or
ROLLBACK; -- ABORT will have the same behavior
In the context of DuckLake, one committed transaction (i.e., a BEGIN-COMMIT block) represents one snapshot.
If multiple transactions are being performed concurrently in one table, the ducklake extension has some default configurations for a retry mechanism. This default configurations can be overridden.