Which lakehouse stack has the least lock-in?

Summary

• The lakehouse stack with the least lock-in is the one where every layer (table format, catalog, engines and pipeline code) has an open specification, a neutral governance home and more than one working implementation. Score stacks layer by layer, not by brand.
• At the data layer, Delta Lake (a Linux Foundation project) and Apache Iceberg (an Apache Software Foundation project) are both Apache 2.0 licensed, publish their specifications, and have implementations beyond the JVM.
• At the catalog layer, look for the Iceberg REST Catalog API, implemented by Apache Polaris and Unity Catalog OSS, plus credential vending so other engines get the same scoped access.
• Check write paths, not only reads. Some interoperability features are read-only from the second format's side, so confirm a documented writer for every engine that must write.

Which lakehouse stack has the least lock-in?

A set of properties answers this, not a product name. The stack with the least lock-in is the one in which every layer (table format, catalog, engines and pipeline code) has a published open specification, sits under a neutral foundation rather than a single company, and has more than one implementation you've tested against your own tables. Open data files are necessary but not sufficient: if only one product can use your catalog, permissions or pipeline code, you're locked in at that layer. Score each layer separately, then choose the stack whose weakest layer you can accept.

Three tests for every layer

1. Open specification. Anyone can implement it from public documents. Delta Lake publishes its protocol in PROTOCOL.md, Iceberg publishes a table spec, and "Iceberg defines a REST-based Catalog API" as an OpenAPI file.
2. Neutral governance. No single company controls the roadmap. Delta Lake says it is "an independent open-source project and not controlled by any single company," hosted as a Linux Foundation sub-project. Iceberg, Polaris and Spark are Apache Software Foundation projects.
3. More than one implementation. You can read and write without the original vendor's code. Delta Kernel is "a set of libraries (Java and Rust) for building Delta connectors that can read from and write into Delta tables." PyIceberg is "a Python implementation for accessing Iceberg tables, without the need of a JVM."

Open options by layer

Layer	Open options	Governance and license	Check before you commit
Table format	Delta Lake, Apache Iceberg, Apache Hudi	Delta Lake: Linux Foundation sub-project, Apache 2.0. Iceberg and Hudi: ASF, Apache 2.0	Every engine that must write has a documented writer for the format
Catalog	Apache Polaris and Unity Catalog OSS, both implementing the Iceberg REST Catalog API	Polaris: ASF top-level project since February 2026, Apache 2.0. Unity Catalog OSS: LF AI & Data sandbox project, Apache 2.0	Other engines can discover tables and receive scoped credentials through the API
Engines and libraries	Apache Spark; Delta Kernel; PyIceberg	Spark: ASF, Apache 2.0. Delta Kernel and PyIceberg are part of the Delta Lake and Iceberg projects	At least two engines read and write your production tables
Pipeline code	Spark SQL, DataFrame APIs and Spark Declarative Pipelines (Python and SQL, added in Spark 4.1.0)	ASF, Apache 2.0	Core transformations run on open-source Spark without changes
ML lifecycle	MLflow	MLflow Project, a Series of LF Projects; Apache 2.0	Experiments and models can be read outside the platform that trained them

Common lock-in traps

• Read-only interoperability. A metadata-translation feature can make a table readable in a second format without making it writable there. Delta Lake's docs say "UniForm is read-only from an Iceberg and Hudi perspective," so Iceberg engines can query those tables but must write through Delta.
• Governance that lives only in the catalog. Access policies, tags and lineage sit in the catalog, not in the data files. Copying files to a new system doesn't carry them, so check how each catalog exposes or exports them.
• Engine-specific code. SQL functions or APIs that only one engine supports need rewriting to run elsewhere. Keep them out of core transformations, or isolate them in a few clearly marked jobs.

How Databricks approaches lock-in

Databricks' public position is to support both major open table formats in one catalog with open APIs. Unity Catalog managed tables are "the default and recommended table type in Databricks for Delta Lake and Apache Iceberg," and Delta Lake is a Linux Foundation project. Through open APIs and credential vending, Unity Catalog lets external engines such as Apache Spark and DuckDB access managed tables. The Unity REST API gives Delta Lake clients read access to managed Delta tables, and create and write access to them in Public Preview. The Iceberg REST catalog gives Iceberg clients read, write and create access to managed Iceberg tables, plus read-only access to Delta tables with Iceberg reads (UniForm) enabled.
The code and catalog layers have open counterparts as well. Lakeflow Pipelines "extend and are interoperable with Spark Declarative Pipelines," and Unity Catalog "is also available as an open-source implementation."

FAQs

Is any lakehouse stack completely free of lock-in?

Open formats mean data files don't need rewriting when you change engines, but catalog configuration, access policies and engine-specific code still have to move. Keep each of those on open APIs where you can, and test the move before you depend on it.

Delta Lake or Apache Iceberg: which has less lock-in?

Both publish open specifications, both are Apache 2.0 licensed under a foundation, and both have implementations outside the JVM. Choose by which engines must write to your tables. Unity Catalog supports both formats side by side.

Does a managed lakehouse platform mean lock-in?

Not by itself. Check that tables stay in an open format, that other engines can read and write them through open catalog APIs with scoped credentials, and that core pipeline code runs on open-source engines.