Platforms

The table format standoff is over and nobody surrendered

Iceberg, Delta and the rest converged on features and moved the war to catalogs. Where the actual lock-in lives in 2026, and what to standardize on.

By The editors · · 4 min

For years the industry treated Iceberg versus Delta as a religious question. The 2026 answer is duller and more useful: the formats converged, and the fight moved up a layer.

Illustrative chart of table format capabilities converging between 2023 and 2026

The convergence is documented. Deletion vectors, variant types and broad engine support now exist across formats, Databricks ships full Iceberg support through Unity Catalog's REST API, and interoperability layers write one table readable as several formats. Choosing a format in 2026 buys less differentiation than it did in 2023, which is what winning looks like when everyone does it.

the catalog is the new lock-in

Access control, table discovery and governance moved into catalogs, and catalogs are where vendors now compete for your commitment. Iceberg's REST catalog specification became the de facto interface, with Apache Polaris graduating to a top-level Apache project in February 2026 as the vendor-neutral implementation. Unity Catalog remains excellent inside Databricks and less portable outside it. That asymmetry, not file metadata layout, is the decision that will still bind you in 2030.

how the war actually ended

It is worth recording how the convergence happened, because the mechanism predicts the next war's ending too. Neither format won converts; both formats copied features. Delta got deletion vectors, Iceberg got them shortly after; Iceberg's hidden partitioning pressure produced equivalents across the aisle; the interoperability layers then made the remaining differences invisible to the engines that matter. Standards wars in infrastructure rarely end with a surrender ceremony. They end when the cost of differing exceeds the marketing value of the difference, and the vendors quietly converge while their keynotes continue the argument for another year.

The residue is a checklist rather than a religion. Streaming-heavy estates still lean one way, some engines still read one format faster than another, and a shop that is contractually married to a single vendor should simply take that vendor's default. For everyone else the format question now costs more in meeting time than the answer returns in differentiation.

the migration nobody needs to rush

A consequence the vendor content will not spell out: if you are on the "wrong" format today, the convergence means doing nothing is usually correct. Interop layers read your tables from both sides, every major engine speaks both dialects, and a rewrite of petabytes to change file metadata is an expensive way to arrive where you already stand. The exceptions are genuine: a governance consolidation that requires one catalog, or an engine commitment that reads one format meaningfully faster at your scale. Absent those, the correct migration budget is zero, and any proposal to spend a quarter converting formats should be read as a request to fund a resume.

What deserves the budget instead is an exit test for the catalog. Before the next renewal, actually export the metadata, actually mount it in a second catalog, actually run the permission suite against the copy. The exercise takes a week, produces a documented number for the cost of leaving, and changes the tone of the renewal call in a way no amount of architectural principle does. Lock-in that has been priced is a commercial term; lock-in that has not is a hostage situation with better catering.

questions for your next procurement call

Since the catalog is where commitment now lives, the diligence questions move up a layer too, and the useful ones are specific. Does the catalog implement the open REST interface as its primary surface, or as a compatibility shim beside a proprietary API where the real features land first. Which of the governance capabilities, masking, row filters, tag propagation, audit export, work through the open interface rather than only through the vendor's own engine. What is written, in the contract rather than the roadmap deck, about metadata export formats and the notice period before an interface deprecation. And the quiet one that sorts vendors fastest: name three competing engines that run in production against this catalog today, with customers willing to say so.

None of these questions is hostile. A vendor with good answers will enjoy them, and a vendor without them will describe your architecture as a journey, at which point you have learned what the reference calls would not have told you. The format war ended because open table metadata made differentiation unprofitable at that layer; whether the catalog layer ends the same way depends less on foundation announcements than on how many buyers ask questions like these before signing, and how many just take the default that came with the warehouse.

verdict

Standardize on the REST catalog interface, treat the format underneath as replaceable plumbing, and be suspicious of any architecture diagram where the catalog and the query engine come from the same invoice. The format war ended in a draw. The catalog war is being decided by default, one procurement cycle at a time, and defaults are how data platforms get married.