Question 1

The Snowflake team asks you to run a nightly job that exports your Delta gold tables to Iceberg. Why do you push back?

Accepted Answer

Delta and Iceberg are both Parquet data files plus a metadata layer, so UniForm can publish Iceberg metadata over the files you already wrote instead of copying anything. The Parquet in a Delta table and the Parquet in an Iceberg table are the same kind of file; what differs is the metadata that lists which files belong to the current snapshot. UniForm uses that fact: set delta.enableIcebergCompatV2 on the table and Databricks writes Iceberg metadata alongside the _delta_log, pointing at the exact same data files. One physical copy, two readable formats, no conversion step. A nightly export instead doubles storage, doubles the write bill, and guarantees the Iceberg copy is hours behind. It also creates a second table that someone will eventually edit independently. Delta and Iceberg differ in metadata, not in the Parquet data files. UniForm writes Iceberg metadata alongside the Delta log over the same files. One physical copy of the data, readable as either format. A nightly export doubles storage and guarantees a stale second copy.

Question 2

Your Snowflake dashboard shows a count that is one load behind what the Databricks notebook shows, on the same UniForm table. Is the table corrupt?

Accepted Answer

No — Iceberg metadata is generated asynchronously after the Delta commit, so Iceberg readers can legitimately lag the Delta log by one or more commits. A write to a UniForm table commits to the Delta log first and returns. Generating the matching Iceberg snapshot happens after that commit, as a separate step, so there is a window where Delta readers see version N and Iceberg readers still see version N minus one. On a table written every few minutes, that window is almost always open when someone compares the two side by side. You can see where Iceberg is by reading the table properties Databricks maintains for the conversion — the converted Delta version and the converted timestamp — and comparing them with the latest version in DESCRIBE HISTORY. The correct reaction is to treat Iceberg reads as eventually consistent with the Delta table, not to declare a bug. Iceberg metadata is produced after the Delta commit, not inside it. Iceberg readers can legitimately trail the Delta log by a commit. Compare the converted Delta version property against DESCRIBE HISTORY. Design consumers for eventual consistency, not for commit-for-commit parity.

Question 3

Finance looks at the storage line after you enabled UniForm on forty tables and asks whether you are now paying for the data twice. What do you show them?

Accepted Answer

Storage grew by the Iceberg metadata files only; the Parquet is shared, so the delta is small and does not scale with row count the way a copy would. UniForm adds Iceberg manifest and snapshot metadata next to the existing _delta_log. Those files describe which Parquet files are in the snapshot, so their size tracks the number of files and the number of commits, not the number of rows. A copy, by contrast, would have doubled the Parquet bytes, which is where the real money is. The number worth watching instead is metadata churn on a high-frequency writer: every commit produces another Iceberg snapshot, so a table written every minute accumulates metadata quickly and benefits from compaction and from expiring old snapshots. Show the storage breakdown by prefix rather than arguing from theory. Only Iceberg metadata is added; Parquet data files are shared. Metadata size tracks file count and commit count, not row count. High-frequency writers accumulate Iceberg snapshots quickly. Compare storage by prefix to prove the data files were not duplicated.

Question 4

A Trino cluster outside Databricks needs to read your UniForm tables. Walk me through how it finds the table and how it gets permission to read the files.

Accepted Answer

Unity Catalog exposes an Iceberg REST catalog endpoint; Trino loads the table through it and UC vends short-lived storage credentials scoped to that table's files. Trino is configured with the Iceberg REST catalog connector pointed at the Unity Catalog endpoint, authenticating as a principal UC knows — typically a service principal with a token. When Trino asks for a table, UC checks SELECT on that table and returns the current Iceberg metadata location. For the data files, UC performs credential vending: it hands back a temporary, scoped cloud credential instead of you pasting a long-lived storage key into the Trino config. That is the governance win — access is still decided by UC grants, and revoking SELECT stops the next request rather than requiring a key rotation. The two things that break this in practice are a principal with no USE CATALOG and USE SCHEMA, and network rules on the bucket that the vended credential cannot overcome. UC acts as an Iceberg REST catalog for external engines. Credential vending returns short-lived, table-scoped storage credentials. Grants in UC remain the access decision, not a shared storage key. USE CATALOG and USE SCHEMA are required alongside SELECT.

Question 5

ALTER TABLE ... SET TBLPROPERTIES to enable UniForm fails on an older table. What prerequisites are you checking, and what does enabling it change permanently?

Accepted Answer

UniForm requires column mapping and a minimum Delta protocol version, and enabling those upgrades the table protocol in a way you cannot cleanly undo. Iceberg identifies columns by field ID, so the Delta table has to use column mapping in name mode before Iceberg metadata can describe it. Turning column mapping on raises the table's reader and writer protocol versions, and a protocol upgrade is recorded in the Delta log as a permanent property of the table. The consequence is that any older client — an external Spark pinned to a stale delta-core, a partner job on an old runtime — can stop being able to read or write the table at all. UniForm also restricts some Delta features on the table, because an Iceberg reader has to be able to interpret the same files. So the pre-flight check is: what else reads this table, on what runtime, and is there a feature on it that UniForm will not allow. Column mapping in name mode is required so Iceberg can use field IDs. Enabling it raises reader and writer protocol versions permanently. Older Delta clients can lose access after the protocol upgrade. Some Delta features are restricted on a UniForm-enabled table.

Question 6

The Flink team wants to write into a UniForm table through the Iceberg catalog so both sides can append. What do you tell them?

Accepted Answer

Iceberg access to a UniForm table is read-only; Delta remains the single writer, so Flink writes to its own table and you ingest from it. UniForm publishes Iceberg metadata derived from the Delta log. The Delta log is the source of truth, and the Iceberg snapshot is a projection of it generated afterwards. An Iceberg writer committing its own snapshot would have no way to make the Delta log agree, so the two metadata layers would diverge and one set of readers would see files the other does not. That is why the Iceberg surface is for readers. The workable pattern is to give Flink its own table — its own Iceberg table, or a Delta table it writes through a supported path — and then merge that into the shared table from Databricks, so there is exactly one writer per table and the lineage shows it. The Delta log is authoritative; Iceberg metadata is derived from it. Iceberg clients read UniForm tables; they do not write them. Two writers against two metadata layers would diverge silently. Give each writer its own table and merge downstream.

Question 7

A partner already publishes Iceberg tables in their own catalog and wants you to query them. Is that UniForm?

Accepted Answer

No — that is the opposite direction: a foreign Iceberg table or catalog federation, where Unity Catalog reads someone else's Iceberg metadata. UniForm is for data you own and write as Delta that you want external engines to read as Iceberg. Reading a partner's Iceberg table is the inbound case: you register their catalog as a connection in Unity Catalog and the tables appear as foreign tables you can query with normal SQL. The data stays in their storage and their catalog remains authoritative, so you get reads, not ownership. The practical constraints are the ones you would expect from a federated read — write support is limited, performance depends on their file layout, and you are now coupled to their refresh cadence and their credentials. If you need to join it hot against your own gold tables repeatedly, materializing a local copy on a schedule is often the honest answer. UniForm is outbound: your Delta tables readable as Iceberg. Foreign Iceberg tables are inbound: you read their catalog. The partner's catalog stays authoritative; you get read access. Repeated hot joins may still justify a local materialization.

Question 8

You are designing a lakehouse where Databricks owns ETL but Snowflake, Trino, and a Flink app all read the gold layer. How do you avoid three copies of the data?

Accepted Answer

One Delta gold layer with UniForm enabled, published through Unity Catalog's Iceberg REST catalog, with per-engine service principals and a documented freshness lag. The physical design is one set of Parquet files written by Databricks, with Delta as the write format and Iceberg metadata published alongside. Unity Catalog is the single catalog: external engines come through the Iceberg REST endpoint with credential vending rather than storage keys, so grants, lineage, and audit cover every reader. The organizational design matters as much as the technical one: declare which tables are published, hold them to a schema contract, and state the Iceberg lag in the contract so nobody builds a reconciliation job on an assumption of exact parity. Publish a narrow set of gold tables rather than the whole catalog, because every published table is an interface you now have to keep stable. The copies you still accept are deliberate ones — a reader that needs sub-second latency or a format you do not publish. One write path in Delta; Iceberg metadata published for readers. UC Iceberg REST catalog plus credential vending for every external engine. Publish a narrow, contracted set of gold tables, not the whole catalog. State the Iceberg freshness lag in the contract, do not leave it implied.