Skip to main content
Delta Lake is a table format that supports Parquet file format and provides time travel and versioning features. When migrating data from Delta Lake to Iceberg, it is common to migrate all snapshots to maintain the history of the data.

​
Overview

Currently, Iceberg supports the Snapshot Table action for migrating from Delta Lake to Iceberg tables.
Since Delta Lake tables maintain transactions, all available transactions will be committed to the new Iceberg table as transactions in order.
For Delta Lake tables, any additional data files added after the initial migration will be included in their corresponding transactions and subsequently added to the new Iceberg table using the Add Transaction action.
The Add Transaction action, a variant of the Add File action, is still under development.

​
Enabling Migration from Delta Lake to Iceberg

The iceberg-delta-lake module is not bundled with Spark and Flink engine runtimes. To enable migration from Delta Lake features, the minimum required dependencies are:

​
Compatibilities

The module is built and tested with Delta Standalone 0.6.0 and supports Delta Lake tables with the following protocol version:
  • minReaderVersion: 1
  • minWriterVersion: 2
Refer to Delta Lake Table Protocol Versioning for more details about Delta Lake protocol versions.

​
API

The iceberg-delta-lake module provides an interface named DeltaLakeToIcebergMigrationActionsProvider, which contains actions that help convert from Delta Lake to Iceberg. The supported actions are:
  • snapshotDeltaLakeTable: Snapshot an existing Delta Lake table to an Iceberg table

​
Default Implementation

The iceberg-delta-lake module also provides a default implementation of the interface which can be accessed by: 
DeltaLakeToIcebergMigrationActionsProvider defaultActions = 
    DeltaLakeToIcebergMigrationActionsProvider.defaultActions();

​
Snapshot Delta Lake Table to Iceberg

The action snapshotDeltaLakeTable reads the Delta Lake table’s transactions and converts them to a new Iceberg table with the same schema and partitioning in one Iceberg transaction. The original Delta Lake table remains unchanged. The newly created table can be changed or written to without affecting the source table, but the snapshot uses the original table’s data files. Existing data files are added to the Iceberg table’s metadata and can be read using a name-to-id mapping created from the original table schema. When inserts or overwrites run on the snapshot, new files are placed in the snapshot table’s location. The location defaults to be the same as that of the source Delta Lake Table. Users can also specify a different location for the snapshot table.
Because tables created by snapshotDeltaLakeTable are not the sole owners of their data files, they are prohibited from actions like expire_snapshots which would physically delete data files. Iceberg deletes, which only affect metadata, are still allowed.In addition, any operations which affect the original data files will disrupt the snapshot’s integrity. DELETE statements executed against the original Delta Lake table will remove original data files and the snapshotDeltaLakeTable table will no longer be able to access them.

​
Usage

Required InputConfigured ByDescription
Source Table LocationArgument sourceTableLocationThe location of the source Delta Lake table
New Iceberg Table IdentifierConfiguration API asThe identifier specifies the namespace and table name for the new Iceberg table
Iceberg CatalogConfiguration API icebergCatalogThe catalog used to create the new Iceberg table
Hadoop ConfigurationConfiguration API deltaLakeConfigurationThe Hadoop Configuration used to read the source Delta Lake table
For detailed usage and other optional configurations, please refer to the SnapshotDeltaLakeTable API.

​
Output

Output NameTypeDescription
imported_files_countlongNumber of files added to the new table

​
Added Table Properties

The following table properties are added to the Iceberg table to be created by default:
Property NameValueDescription
snapshot_sourcedeltaIndicates that the table is snapshot from a Delta Lake table
original_locationlocation of the Delta Lake tableThe absolute path to the location of the original Delta Lake table
schema.name-mapping.defaultJSON name mapping derived from the schemaThe name mapping string used to read Delta Lake table’s data files

​
Example

Here’s a complete example of migrating a Delta Lake table to Iceberg: 
import org.apache.iceberg.catalog.TableIdentifier;
import org.apache.iceberg.catalog.Catalog;
import org.apache.hadoop.conf.Configuration;
import org.apache.iceberg.delta.DeltaLakeToIcebergMigrationActionsProvider;

String sourceDeltaLakeTableLocation = "s3://my-bucket/delta-table";
String destTableLocation = "s3://my-bucket/iceberg-table";
TableIdentifier destTableIdentifier = TableIdentifier.of("my_db", "my_table");

// Iceberg Catalog fetched from engines like Spark or created via CatalogUtil.loadCatalog
Catalog icebergCatalog = ...;

// Hadoop Configuration fetched from engines like Spark 
// and have proper file system configuration to access the Delta Lake table
Configuration hadoopConf = ...;
    
DeltaLakeToIcebergMigrationActionsProvider.defaultActions()
    .snapshotDeltaLakeTable(sourceDeltaLakeTableLocation)
    .as(destTableIdentifier)
    .icebergCatalog(icebergCatalog)
    .tableLocation(destTableLocation)
    .deltaLakeConfiguration(hadoopConf)
    .tableProperty("my_property", "my_value")
    .execute();

​
Migration Workflow

1

Add required dependencies

Ensure the iceberg-delta-lake module and Delta Standalone dependencies are available in your classpath.
2

Verify Delta Lake compatibility

Check that your Delta Lake table uses a compatible protocol version:
  • minReaderVersion: 1
  • minWriterVersion: 2
3

Prepare catalog and configuration

Set up your Iceberg catalog and Hadoop configuration with proper credentials and access to both source and destination locations.
4

Execute snapshot

Run the snapshotDeltaLakeTable action with the appropriate configuration:
DeltaLakeToIcebergMigrationActionsProvider.defaultActions()
    .snapshotDeltaLakeTable(sourceDeltaLakeTableLocation)
    .as(destTableIdentifier)
    .icebergCatalog(icebergCatalog)
    .tableLocation(destTableLocation)
    .deltaLakeConfiguration(hadoopConf)
    .execute();
5

Verify migration

Query the new Iceberg table to verify:
  • Row counts match
  • Schema is correct
  • Historical snapshots are preserved
  • Data is readable
6

Update applications

Switch read and write workloads to the new Iceberg table.

​
Best Practices

The snapshot action preserves all Delta Lake transactions as Iceberg snapshots, maintaining full lineage and time-travel capabilities.
Consider specifying a different tableLocation for the Iceberg table to achieve full storage isolation from the Delta Lake table.
Do not run VACUUM or DELETE operations on the source Delta Lake table after migration, as this will break the Iceberg table’s ability to read the data files.
Large Delta Lake tables with extensive transaction history may take longer to migrate. Monitor the process and plan accordingly.
Before migrating production tables, test the migration process on a smaller table or subset of data to validate the workflow.

​
Limitations

  • Tables created via snapshotDeltaLakeTable cannot run expire_snapshots or other operations that physically delete data files
  • Only Delta Lake tables with protocol versions minReaderVersion: 1 and minWriterVersion: 2 are supported
  • The Add Transaction action for incremental updates is still under development

Build docs developers (and LLMs) love

Get started for freeTalk to us