Microsoft has added write support for Apache Iceberg tables through the OneLake table APIs in Fabric, extending an endpoint that previously supported read-only Iceberg metadata operations. Iceberg REST Catalog-compatible clients can now create native Iceberg tables, commit new snapshots and request short-lived storage credentials through the same OneLake table endpoint. A separate additional table metadata API is in preview for descriptions and key-value tags on tables and columns.
The change affects data teams that use engines outside Fabric but want to publish tables into OneLake without copy jobs or custom connectors. Microsoft names PyIceberg, Snowflake and DuckDB as examples of clients that can use the endpoint, and says Snowflake supports the APIs through its catalog-linked database feature. ClickHouse has also announced support for writing Iceberg tables directly to OneLake through these APIs.
What the write API supports
The Iceberg REST Catalog API is available at https://onelake.table.fabric.microsoft.com/iceberg. The endpoint already supported namespace and table discovery for schemas and tables in a Fabric data item. The new operations add table creation, metadata commits, table deletion and credential vending.
The write workflow uses both the catalog endpoint and OneLake storage. A client creates or loads a table through the Iceberg REST Catalog endpoint, writes data files and metadata files to OneLake, and then commits the metadata update through the catalog endpoint. The commit request carries the metadata update; it does not carry table rows in the request body.
Commits use optimistic concurrency checks. If a conflicting update has already changed the table state, the commit fails instead of overwriting the newer state. Credential vending returns temporary storage credentials for a table, so clients can write data files without maintaining separate long-lived storage access.
The drop table operation needs particular care. It removes the table from the catalog and deletes its OneLake directory, including data and metadata. Microsoft says it should not be used to remove only virtual Iceberg metadata from a Delta Lake table.
Native Iceberg and virtual metadata
The write operations apply to native Iceberg tables, including tables created through the new create table operation. Virtual Iceberg metadata generated for Delta Lake tables remains a read compatibility feature for Iceberg clients. It does not support Iceberg catalog commits.
That distinction matters in mixed Delta Lake and Iceberg estates. If a team wants to update a Delta Lake table, it still needs to write to the source table with a Delta Lake-compatible writer. OneLake table format virtualisation can make Delta Lake tables readable to Iceberg clients and Iceberg tables usable across Fabric workloads, but it is not the same as committing Iceberg updates to a native Iceberg table.
The OneLake implementation maps Fabric schemas to Iceberg namespaces. Where a data item does not support schemas, the APIs provide a fixed dbo schema for compatibility with clients. The current namespace implementation is one level deep, although the Iceberg REST Catalog standard supports multi-level namespaces.
Client and permission requirements
Clients need to support the Iceberg REST Catalog operations used by OneLake, including the way vended credentials are applied to storage locations. OneLake returns HTTPS credential prefixes, while Iceberg metadata uses ABFS locations, so clients have to account for both URI forms when choosing a credential. Returned SAS values should be treated as secrets and refreshed before their expiry.
Access depends on Microsoft Entra ID. Read operations require permission to read the target tables. Write operations require write access to the target Fabric data item and OneLake location, through the relevant item, workspace or OneLake data access role.
Applications also need to obtain tokens for the Azure Storage token audience, https://storage.azure.com/. Microsoft says the OneLake table API endpoint accepts the same token audience as the OneLake filesystem endpoints. Snowflake examples also have further constraints, including public network access to OneLake and, for Snowflake on Azure writes, the Fabric capacity and Snowflake instance being in the same Azure region.
Metadata for context
The additional table metadata API is in preview. It lets clients read and write descriptions and key-value tags for a table and its columns through a common REST route, rather than through a format-specific catalog API. The intended uses include recording a table’s business purpose, its owning team or how a column should be interpreted.
The metadata API also works through internal OneLake shortcuts. Updates apply to the target table, so users see the same descriptions and tags whether they read through the shortcut or the source. That is useful where shortcuts are used to organise data access across workspaces, because the descriptive metadata does not have to be maintained separately for each route.
For Fabric teams, the main design question is ownership of writes. Engines can publish native Iceberg tables into OneLake, but permissions, credential vending, commit handling and deletion behaviour still need operational rules. The preview metadata API adds another governance surface, because descriptions and tags become part of how people and AI agents interpret the data.
When Iceberg writers can commit directly to OneLake, data teams have to decide which engine owns writes, how credentials are handed out and how Fabric metadata is governed, which is work ECS's Data topic covers across Microsoft Fabric, Power BI, SQL Server and Dataverse. Sessions and workshops give attendees room to compare implementation patterns with governance controls from production Fabric projects. Bring the table formats, shortcut designs and access questions that are difficult to settle from documentation alone.
This article was written by the ECS editorial team with the assistance of Amal Agent, run.events' AI assistant, which supported the research, drafting and proofreading.