Apache Iceberg vs Delta Lake for SaaS Data Export Targets

A folder of Parquet files sitting in S3 or GCS is not a table. There's no atomic write, no guarantee a reader mid-scan sees a consistent snapshot, no enforced schema, no way to ask what the data looked like last Tuesday. Apache Iceberg and Delta Lake both fix this by adding a metadata layer on top of the files, one that tracks which files currently belong to the table, what the schema is, and what the table looked like at every prior commit. Readers query the metadata, not the storage prefix, and that single design choice is what turns a pile of files into something a warehouse engine can trust.

For a SaaS vendor shipping data export to a customer's own warehouse or lakehouse, this distinction stops being academic fast. The vendor doesn't control the destination. Whatever format lands there has to be something the customer's engines can read directly, without a translation layer or a proprietary bridge nobody outside the vendor's walls can maintain. And the operational weight of running an open table format, catalog registration, compaction, vacuuming, schema migration, doesn't disappear just because the vendor picked a format. It just shifts between vendor and customer depending on which one was chosen. That's the frame for the rest of this piece: which environment the customer actually runs, how well the format travels across a customer base that's rarely uniform, and how much operational load the vendor ends up carrying.

How the two formats structure metadata differently

Delta Lake tracks table state through a transaction log: a _delta_log/ directory full of sequentially numbered JSON commit files sitting next to the actual Parquet data. Every 10 commits by default, Delta writes a Parquet checkpoint that summarizes the table's state up to that point, so a reader doesn't have to replay the entire log from commit zero. Reading current state means starting at the last checkpoint and replaying forward from there. Atomicity comes from a put-if-absent operation on the commit file's name: a writer trying to create version N fails outright if version N already exists, then re-reads and retries. It's a log, and logs are simple to reason about.

Iceberg takes a different shape entirely, more tree than log. A top-level metadata file points to a manifest list, which in turn points to manifests carrying file-level stats like null counts and row counts. Atomicity happens at the catalog layer, through a compare-and-swap on the pointer to the current metadata file. Query planning walks down the tree and uses the partition ranges recorded in the manifest list to skip entire manifests outright, rather than listing the storage prefix and figuring things out file by file. Planning cost tracks with how many files actually match the query, not with how large the table has grown overall.

In practice, both formats plan queries fast enough for typical tables, making query planning speed invisible day to day. The gap opens up on tables with a very large number of partitions and very frequent commits, where Iceberg's tree structure scales more gracefully than Delta's log replay. Delta's checkpoints keep replay cost bounded for most real workloads, but on large tables accumulating many commits, that replay does get heavier over time.

The partitioning model is where the difference actually bites for SaaS export schemas. Delta uses Hive-style partitioning: partition values get baked into directory paths, and a query has to filter explicitly on the partition column to get any pruning benefit. Iceberg does hidden partitioning instead. The partition is a transformation of a real column, recorded in the metadata itself, so a filter on event_ts prunes automatically and the person writing the query never needs to know how the table is laid out on disk. Iceberg also supports partition evolution: the partition layout can change without rewriting existing data. Old files keep their old partitioning, new files use the new spec, and Iceberg plans across both without complaint. Delta's answer to the same underlying problem is liquid clustering, which replaces static partitions with incremental clustering that can be adjusted at any time. It solves a related problem differently, and it's available to Databricks users on recent runtimes.

Where the ecosystem stands in 2026: adoption, engine support, and catalog fragmentation

Neither format has won, and framing this as a contest with a winner misses what's actually happening. Adoption surveys point to Iceberg pulling ahead on a three-year horizon: 29% of organizations plan to adopt it, against 23% for Delta Lake. Among large enterprises evaluating Iceberg specifically, usage jumped to 38% in the most recent period covered, up from just 12% in 2024. Amazon S3 Tables, AWS's managed Iceberg offering, grew to host more than 400,000 tables in its first year, which is a real signal that Iceberg has moved past the experimentation stage into production workloads at scale.

None of that erases Delta's installed base, though, which is large and not going anywhere soon. Databricks reports Delta Lake running in production at more than 10,000 companies, including over 60% of the Fortune 500. Any SaaS vendor with a meaningful enterprise customer base is very likely writing into Delta Lake environments already, regardless of which format the vendor's own engineers prefer.

Where the two formats really diverge is engine support. Iceberg's reach is broad by design: Spark leads with 96.4% of surveyed users, Trino follows at 60.7%, Flink at 32.1%, DuckDB at 28.6%. Multi-engine querying against the same Iceberg tables is already the default pattern, not an edge case. Independent engines that read Iceberg natively include BigQuery, Snowflake, Redshift, Athena, Trino, ClickHouse, DuckDB, Dremio, StarRocks, Doris, Druid, Firebolt, and Microsoft OneLake, which is a longer list than most format comparisons account for. Delta's engine support has grown too, largely through the delta-kernel project, but the perception that Delta is coupled tightly to Spark and Databricks persists for a reason: non-Spark engine support has historically arrived second, after the experience on the vendor's own platform was already mature.

Catalog choice adds another layer of fragmentation that's specific to Iceberg. No single catalog dominates: AWS Glue leads at 39.3%, Nessie is at 28.6%, Amazon S3 Tables at 25%, Apache Polaris at 21.4%, and Hadoop/Hive Metastore still holds 17.9%. For a SaaS vendor, the catalog layer is a decision the customer makes. An export feature that assumes one specific catalog will break against a meaningful share of the customer base. Building catalog-agnostic, or building against the REST Catalog standard, which most of the newer catalogs (Polaris, Lakekeeper, and increasingly Glue and S3 Tables) already speak, solves this.

The convergence moves: UniForm, managed Iceberg on Databricks, and what they resolve

The two formats are converging at the platform level faster than the underlying specs are converging with each other. Databricks now supports both Delta Lake and managed Iceberg tables natively inside Unity Catalog, which is a meaningful shift from a company whose product used to be synonymous with Delta alone.

The mechanism doing most of the work here is UniForm, which writes Iceberg metadata alongside the standard Delta metadata so that Iceberg-native clients can read a Delta table without any conversion step. A read bridge, not a two-way door, is what UniForm actually is. Writes still go through Delta and Spark; Iceberg clients only get to read. A few constraints matter for anyone considering this for a SaaS export path. Column mapping has to be turned on for the table. Deletion vectors can't be used alongside UniForm. And Delta's version numbers don't map cleanly onto Iceberg's snapshot IDs, which complicates anything downstream that tries to reason about table history across both formats at once. UniForm is a genuinely useful bridge for customers who need reads on the Iceberg side of a table the vendor is committed to writing as Delta, but it does nothing for a customer whose stack needs to write from a non-Delta engine.

The convergence is running in the other direction too. Iceberg v3, supported on Databricks Runtime 18.0 and later, adopts several features that started life on the Delta side: deletion vectors, row lineage, and the VARIANT type. Dremio brought Iceberg v3 to general availability in Dremio Cloud in April 2026, which puts those same three features, deletion vectors, row lineage, VARIANT, into the hands of Dremio's users as well. The feature gap between the two formats is narrowing from both directions at once, even as the underlying metadata structures stay distinct.

Mapping customer environments to format fit: the practical compatibility matrix

The real question for a product team is which destination environments the actual customer base runs. It's which destination environments the actual customer base runs, and that answer varies enough by industry and company size that a single default rarely holds for an entire customer roster.

A long list of environments treat Iceberg as native or clearly preferred. Snowflake reads and writes Iceberg tables directly. Google BigQuery supports Iceberg as both external tables and managed tables. AWS Athena queries Iceberg natively, with AWS Glue Data Catalog handling schema and partition metadata and AWS Lake Formation layering on column-level, row-level, and cell-level access control. Trino, DuckDB, Dremio, StarRocks, and RisingWave all work with Iceberg out of the box. On the streaming side, Confluent Tableflow and StreamNative Ursa both write directly into Iceberg tables on cloud object storage, which removes the need for a bespoke connector between a streaming pipeline and the lakehouse.

Delta's stronghold is different in character, narrower but deeper. Databricks is where Delta is truly native: Unity Catalog, table optimization, and maintenance routines are all built around it, and the integration there goes further than anywhere else Delta is used. Any customer running a primarily Spark-based stack tends to get real value from Delta's tooling, including liquid clustering and Change Data Feed, both of which are tightly woven into that ecosystem. Delta Sharing, delivered through Unity Catalog, is described by Databricks as the most widely adopted open protocol for zero-copy data sharing across clouds and platforms, and that claim matters for customers who need to hand data to a third party without duplicating it.

Plenty of customers don't sit cleanly in either camp. Teradata supports both Iceberg and Delta Lake at enterprise grade, giving customers freedom to choose their storage, catalog, and query engine across major clouds, on-prem, and hybrid setups. Cloudera's open data lakehouse ingests batch and streaming data through NiFi, Flink, and Kafka, processes that same copy of data with Spark, and then runs analytics or AI workloads through its Data Visualization, Data Warehouse, and Machine Learning tools, with Iceberg as the open table format underneath, on private infrastructure or any public cloud. For a SaaS vendor whose customer base spans this kind of variety, Iceberg's engine neutrality reads as the lower-risk default. The same table, unmodified, can be read by Spark, Flink, Trino, Athena, Redshift, Snowflake, BigQuery, DuckDB, and more than thirty other tools, without the vendor duplicating data for each one.

Operational overhead the vendor absorbs depending on format choice

Shipping a data export feature is a running operational commitment. The vendor has to write data reliably at scale into storage it doesn't control, often across dozens or hundreds of customer destinations at once. Someone has to register the table with the right catalog so the destination environment can find it. Small files pile up fast under frequent incremental writes, and compaction has to happen somewhere or query performance at the customer's end degrades. Schema evolution needs coordinating whenever the vendor's own data model changes. And all of it has to happen under encryption, respecting whatever data residency rules apply, sometimes with private-cloud deployment required for regulated customers.

Iceberg makes catalog dependency mandatory: the vendor has to register tables somewhere the customer's engines can look, using Glue, Polaris, Nessie, Lakekeeper, or a catalog built to the REST standard that the vendor stands up itself. That's real infrastructure to build and run, though the REST Catalog standard has narrowed the integration surface considerably compared to a few years ago. In exchange, Iceberg's partition evolution and hidden partitioning cut down on a recurring cost: changing how data gets partitioned later doesn't require rewriting everything already exported. And Iceberg's atomicity model, resting on a catalog compare-and-swap rather than a centralized lock service, simplifies concurrent writes across many destinations at once.

Delta's profile runs the other direction on catalog dependency. A Delta table can be discovered through its filesystem path alone, with no catalog registration required, which lowers setup friction for some customer environments considerably. What Delta pushes onto the operational side instead is maintenance: OPTIMIZE for compaction and VACUUM for cleaning up stale files are recurring jobs that someone, vendor or customer, has to own, and that ownership needs to be spelled out in the integration contract rather than assumed. If the vendor wants to serve both a native reader for one table format and Iceberg-native readers off the same table, UniForm adds its own maintenance burden: deletion vectors and column mapping settings carry constraints that have to be respected across the table's lifetime. On the upside, Delta's Change Data Feed is a genuinely useful primitive for incremental export, exposing row-level changes between versions so downstream systems can process only what changed rather than rescanning the whole table.

Some vendors sidestep the whole build decision by embedding a white-label integration layer instead of writing the format logic themselves. Dataddo, which is listed on the official Apache Iceberg site among ecosystem tools, is one example of a platform built around exactly this pattern: handling the export mechanics so the SaaS vendor doesn't have to staff a team around catalog APIs and compaction jobs. That doesn't remove the format decision, Iceberg versus Delta still depends on where the customer's environment lives, but it does change who inside the vendor's org has to carry the operational weight day to day.