Unity Catalog Becomes a Full Iceberg Catalog: What GA Really Means

Managed Iceberg, Iceberg v3, and Foreign Iceberg are GA. Here is what changes for how you build.

Unity Catalog Becomes a Full Iceberg Catalog: What GA Really Means

For years the conversation about open data was about the table format. Delta or Iceberg. Which one wins. Which one you should pick.

But the table format was never the whole story. A format lets many engines read the same files. It does not decide who is allowed to read them, how they stay fast, or how they get shared across teams and companies.

That job belongs to the catalog.

In 2026 Databricks moved a large set of Apache Iceberg capabilities into general availability inside Unity Catalog. Managed Iceberg, Iceberg v3, and Foreign Iceberg are now GA. The quiet headline is this. Unity Catalog is no longer just a Delta catalog that can talk to Iceberg. It is a full, production ready Iceberg catalog. Unity Catalog now also governs a new FILE type for unstructured data like PDFs and images.

Let us slow down and understand what that means, and why it matters for the way you build.

A short reminder: format versus catalog

Think of a library. The books are your data files. The format is how each book is printed and bound. Two libraries can use the same printing style.

The catalog is the front desk. It knows which books exist, who can borrow them, where they live, and how to keep the shelves in order.

You can have a great printing style and still have a chaotic library. The catalog is what makes the collection usable.

If this idea is new to you, the Unity Catalog lesson walks through governance from the ground up, and the Delta Lake lesson explains how open table formats work in plain terms.

What is now generally available

A few capabilities moved to GA together. Here is the plain version of each.

Managed Iceberg tables. You can now create, read, write, optimize, govern, and share Iceberg tables directly in Unity Catalog. The catalog treats them as first class, not as a side path. That includes automatic maintenance, which we will come back to.

Iceberg v3. This is the newer version of the Iceberg spec. It adds deletion vectors, row tracking, and the VARIANT type. In simple words, updates and deletes get faster, incremental processing gets easier, and semi structured data gets a proper home.

Foreign Iceberg. You can register Iceberg tables that live in another catalog, such as AWS Glue or Snowflake Horizon, and govern them through Unity Catalog without moving or copying the data. The data stays where it is. The control moves to one place.

External sharing to Iceberg clients. Using the OpenSharing protocol (the next evolution of Delta Sharing), you can share live data with any Iceberg REST compatible client, such as Trino, Flink, or Snowflake, without manual exports.

There is more in preview, including cross engine access control and Iceberg compatible materialized views. But the GA list above is the part you can rely on today.

What actually changes for you

The clearest way to feel a release is to compare before and after.

Before, supporting many engines often meant keeping many copies. A Delta copy for Databricks. An Iceberg copy for another tool. Maybe a third extract for a partner. Every copy drifts. Every copy costs money. And when two dashboards disagree, nobody knows which copy was right.

After, you write once into a governed Iceberg table in Unity Catalog. Spark, Trino, DuckDB, pandas, or Snowflake read the same table through open APIs. One copy. One set of access rules. One source of truth. This is further simplified by Databricks Lakeflow, which is now GA for unified ingestion and orchestration.

One governed table in the center, many engines reading from it through open APIs

Here is the shape of that single write path. Creating a managed Iceberg table is ordinary SQL.

CREATE TABLE main.sales.orders (
  order_id   BIGINT,
  customer   STRING,
  amount     DECIMAL(10,2),
  order_ts   TIMESTAMP
)
USING ICEBERG

You write to it the same way you write to any table.

INSERT INTO main.sales.orders
SELECT order_id, customer, amount, order_ts
FROM main.staging.orders_raw

The difference is what happens next. An outside engine that speaks the Iceberg REST Catalog API can read that exact table, with Unity Catalog still enforcing who is allowed to see what. You did not export anything. You did not grant broad storage keys. The catalog handed out scoped access on your behalf.

A concrete look at Iceberg v3

The v3 features sound abstract until you connect them to daily work.

Say a customer asks to be removed for privacy reasons. You run a delete.

DELETE FROM main.sales.orders
WHERE customer = 'C-10492'

On older table formats, a small delete like this could rewrite large data files just to drop a few rows. Deletion vectors change that. The row is marked as removed in a small side file, and the heavy rewrite is avoided. Merges, updates, and deletes get lighter.

Row tracking is the next piece. It lets engines see what changed between versions, which is the foundation for efficient incremental processing. That is the same idea you practice in the incremental processing lesson.

VARIANT is the third. It gives semi structured data a real type instead of a string you parse everywhere.

CREATE TABLE main.events.raw (
  event_id   BIGINT,
  payload    VARIANT
)
USING ICEBERG

Now you can store nested JSON once and let engines read into it directly. If messy or nested data is part of your work, the file formats lesson explains why this is a real win.

Governance without moving data

Foreign Iceberg is the part that surprises people.

Large companies rarely have one catalog. They have several, often by accident, often across clouds. The usual fix is a year long migration project.

Foreign Iceberg offers a calmer path. You register the external tables, govern them in Unity Catalog, and leave the data in place. You get discovery, access control, and lineage across the whole estate without a forklift move. Unity Catalog becomes a single pane of glass over catalogs you did not even build.

Many separate catalogs viewed through one single lens, without moving the data

If your team is still untangling older systems, the post on decommissioning Hive Metastore safely pairs well with this idea, and Unity Catalog best practices covers how to structure namespaces before you scale.

Tables that stay fast on their own

Open tables only help if they stay fast at production scale.

This is where Unity Catalog does something most catalogs do not. Predictive Optimization watches how tables are used and decides what maintenance to run and when. Liquid Clustering adapts the data layout to real query patterns instead of fixed partitions you guessed at months ago.

The result is fewer manual OPTIMIZE jobs and fewer late night tuning sessions. And because the layout improvements live in the files, even engines outside Databricks read faster.

If you want the intuition behind clustering and layout, the partitioning and performance lesson builds it step by step.

How a data engineer should think about this

A good way to absorb a release like this is to ask three questions of your own platform.

Where am I copying data only because two engines wanted different formats? That copy may no longer be needed.

Where is governance enforced in one engine but not another? Cross engine control is the direction the catalog is heading, so design for one policy, not many.

Where am I hand tuning tables that a catalog could maintain for me? That is effort you can give back to real problems.

You do not need a paid workspace to start practicing the skills underneath all of this. Governance, Delta, incremental processing, and performance can all be explored in Databricks Free Edition today.

Continue Learning

The format wars made for good headlines. The real work is quieter. Build data that one catalog can govern, many engines can read, and no one has to copy. That is the lakehouse finally behaving the way we always described it.