Delta Lake is the default for Databricks users. Apache Iceberg is winning the "Open Ecosystem" war with support from Snowflake, AWS, and Netflix.
I've migrated production data onto both of these formats, and I'll tell you upfront: the Delta-vs-Iceberg conversation is more political than technical in 2026. Both are mature, both support ACID, both have time travel, both have schema evolution, and both have active communities. What actually changes between them is which engines read them natively and which vendor's roadmap you're betting on.
A bit of history helps. Data lakes — raw files on S3, ADLS, or GCS — used to be notoriously unreliable. No transactions, no schema enforcement, concurrent writers would corrupt each other, and "what changed last Tuesday?" had no answer. Table formats fixed that by layering a metadata protocol on top of the files.
Delta Lake came out of Databricks in 2019, initially closed-source, later Apache 2.0. It was designed hand-in-glove with Apache Spark and the Databricks runtime. The defining features people care about in production are Z-Order clustering and the newer Liquid Clustering, both of which give you genuinely better file-skipping than Iceberg's default layout if you tune them.
Apache Iceberg came out of Netflix in 2018. It was built to fix the operational nightmares of Hive tables at petabyte scale — slow LIST calls on S3, partition evolution being basically impossible, and metadata corruption on concurrent writes. Iceberg was engine-neutral from day one: the spec is the contract, and any engine (Spark, Trino, Flink, Snowflake, DuckDB) can implement it.
WHERE date_trunc(...) hints. Delta gets similar ergonomics via Liquid Clustering but it's a different mental model.Both formats need maintenance. Delta needs OPTIMIZE and VACUUM. Iceberg needs rewrite_data_files and expired-snapshot cleanup. Teams that skip this for three months end up with 100,000+ tiny files and query latency that makes them angry at the format when the real issue is a missing cron job. Pick whichever format your team will actually remember to maintain.
This one really does come down to ecosystem and engine mix. Here's how I frame it.
Choose Delta Lake if:
For a growing number of teams the right answer is: pick one as primary, use UniForm or the Iceberg-read connectors on the other side, move on with your life. The failure mode I see most often isn't picking the "wrong" format — it's spending three months debating while real work doesn't get done. If you're on Databricks, start with Delta + UniForm. If you're on Snowflake, start with Iceberg on external volumes. If you're building fresh on open compute (Trino, Flink, DuckDB), start with Iceberg.
One thing worth watching: the Iceberg REST Catalog ecosystem is evolving fast. Polaris (Snowflake), Unity Catalog OSS (Databricks), Nessie, Gravitino, and others all speak the same catalog API. That's the real future — the format matters less when the catalog is portable. Both Delta and Iceberg are getting pulled toward that world.
Yes, and it's supported at several levels. Databricks can read external Iceberg tables directly via Unity Catalog. And via UniForm, a Delta table on Databricks can expose itself with Iceberg metadata so Snowflake, Trino, and others read it as Iceberg with zero data duplication. If you're mostly on Databricks but need to share tables with an Iceberg-native engine, UniForm is usually the smoothest path.
Yes — Apache 2.0 license. The core format and protocol are fully open. What's sometimes confusing is that Databricks ships optimizations (Photon, Liquid Clustering tuning, etc.) that make Delta perform better on Databricks than on raw open-source Spark. The format itself is open; the most aggressive performance engine around it is proprietary.
Iceberg has broader multi-engine adoption — Snowflake, AWS, Google, Cloudera, DuckDB, and Trino all treat it as a first-class format. Delta has deeper single-ecosystem depth inside Databricks and significant Microsoft Fabric backing. Both are winning in different arenas. If I had to bet on the default format for a new open data platform today, I'd bet Iceberg — mostly because every warehouse vendor ships Iceberg reads and only one ships Delta reads natively.
UniForm is a Databricks feature that lets a Delta table expose Iceberg metadata alongside Delta metadata in the same storage location. The data files (Parquet) are shared; only the metadata is dual-written. Use it when you're primarily on Databricks (so you want Delta's writer-side features) but need external engines like Snowflake or Trino to read the tables as Iceberg. It's close to zero operational cost and eliminates the "pick one format" anxiety for most mid-size teams.
Both handle streaming well now. Delta via Structured Streaming is the most battle-tested combo if you're on Spark — the writer is highly optimized and the `_checkpoints` story is mature. Iceberg streams well via Flink and, more recently, Spark Structured Streaming. If you need true minute-level MERGE-heavy upserts at huge scale, Apache Hudi is still worth a look — it was purpose-built for that shape of workload and pre-dates both of these formats.
Both support schema evolution — adding and renaming columns is safe on both. Iceberg has a meaningful advantage on partition evolution: you can change a table's partitioning scheme without rewriting historical data because Iceberg tracks partition specs per-snapshot. Delta supports re-clustering via Liquid Clustering but traditional `PARTITION BY` changes are more invasive. If your partitioning needs evolve over time (hourly → daily, or switching partition columns), Iceberg is more forgiving.
Both need regular maintenance. Delta has `OPTIMIZE` (bin-packing / Z-Order / Liquid Clustering reorganization) and `VACUUM` (removes old files past a retention threshold). Iceberg has `rewrite_data_files`, `expire_snapshots`, and `remove_orphan_files`. In both cases, if you skip maintenance for months, small-file problems will ruin query performance. On Databricks, auto-OPTIMIZE and Predictive Optimization handle this automatically; on open-source Iceberg you typically schedule the maintenance procedures via Airflow or equivalent.