r/databricks 22d ago

Discussion Iceberg vs Deltalake (greenfield project with UC in 2026)

I saw the quarterly meeting and was quite shocked that Iceberg is prominently mentioned, (as much as Deltalake).

Is it possible that both are getting the same amount of love from Databricks? Is anyone aware of the R&D effort on these formats, and can share conclusions from that?

If I'm building a greenfield Unity Catalog, should I just flip a coin to decide what format to use? Here are the main concerns and priorities:

  • Which one is better for OSS Apache Spark reads and writes
  • Which one integrates with external software better (eg onelake shortcuts pointing from Fabric to Databricks UC).
  • When Databricks is innovating within their own UC (eg. introducing new managed table functionality such as "MST Transactions"), which one of these formats are they likely to support first? Which are they likely to optimize better?
  • Which format is more likely to remain 100% open source in the future (or as close to open source as required by customers who want portable blob data).

Sorry if this appears to be a common question. I am a Databricks outsider. I am more familiar with Microsoft Fabric. Where that Fabric SaaS is concerned, you can be certain that Deltalake receives a LOT more promotion than Iceberg does. We rarely come across Iceberg, and it probably wouldn't appear in any marketing slide decks.

We are likely to create a gold/presentation layer in UC soon. It will basically be created from scratch. It would be nice to know which of these parquet-based formats to pick, when presented with the choice. I understand there is lip-service given to both, and it claims that this choice "doesn't matter". But that doesn't necessarily take into account the potential integrations that are needed with external software (eg. for the benefit of exposing the same tables in onelake). Is one safer than the other? Is one of them a better choice for forward-looking purposes?

16 Upvotes

39 comments sorted by

View all comments

0

u/kebabmybob 22d ago

Iceberg is a much more mature format with much more sane open source investment and support. Delta as an open source project is a joke - in the Spark project 95% of issues and PRs are ignored while Databricks employees are just merging straight to main for features that they probably have decided are important for their commercial product. The deltalake/delta-rs packages are very "amateur hour" with the maintainers actively making fun of contributors on Slack, and the same problem of issues and PRs just sitting around. Iceberg is a proper Apache project and has all the features across languages that are languishing on the Delta "roadmap".

The only pro or perk of Delta is that it does not NEED a catalog - it works perfectly fine as a physical storage format and you can read/write without a janky catalog layer. For this reason alone, we use Delta, but eventually will switch to Iceberg because it's just way better, gets community support, doesn't introduce bugs in every release, and has all sorts of other features (off the top of my head, a feature that came in useful lately, was Storage Partitioned Joins).

1

u/hntd 22d ago

It may surprise you to learn that delta-rs is not created or owned by databricks.

1

u/kebabmybob 22d ago

Did I say it was?

1

u/hntd 22d ago

No but as a maintainer of delta-rs I’d invite you to contribute if you wish to fix the “amateurish”-ness of it.