Databricks made two sharing features generally available on 11 September 2026: sharing and reading foreign Iceberg tables, and sharing and reading foreign schemas and foreign tables, both over OpenSharing (release notes). Foreign here means the data lives somewhere else, reached through Lakehouse Federation, and the release note is explicit that providers can share it without copying data into Databricks.
What actually changed #
Before this, a share was a thing you had staged in Unity Catalog.
If the data you wanted to send a partner sat in a Snowflake warehouse, a Postgres instance or a foreign Iceberg catalog, the path was to ingest it first, land it in a table, and share the table. Now the federated object itself goes in the share. For foreign Iceberg tables, recipients can read them with external Iceberg clients, so the other end doesn't have to be a Databricks customer either.
That matters most during the long middle of a migration, when half your data is still in the old system. We have watched teams build ingestion pipelines whose only purpose was to make data shareable, and then keep those pipelines running for years after everyone forgot why. This removes the reason to build them.
The cost sentence is the important one #
Buried in the same release note. Sharing foreign schemas and tables materialises data on the provider's side, which incurs compute and storage costs. So the copy did not disappear. It moved, and it moved onto your bill instead of into your catalog.
That is a different trade than it first looks. You have swapped a pipeline you control, with a schedule you set and a cost you can attribute to a job, for platform-managed materialisation triggered by whatever your recipients do. Databricks publishes guidance on incurring and checking OpenSharing costs, and we would read it before turning this on for anything wide. If you share a foreign schema and a recipient starts scanning it hourly, the invoice is yours.
Where this lands in the guide #
This changes what we say in Sharing, Clean Rooms, and Marketplace. The old rule of thumb was that anything you wanted to share had to be a governed table in Unity Catalog first, so sharing was a downstream concern you handled after ingestion. Now sharing can sit alongside federation, and the question becomes which data deserves a real pipeline and which is fine as a federated passthrough.
It also affects Migration. One of the harder arguments in a phased migration is what to do about downstream consumers who read from the legacy system. Federated sharing gives you a way to keep serving them from the source while you move the pipelines, rather than forcing a cutover on their schedule.
Our general advice on Delta Sharing doesn't move. Open protocol, recipient doesn't need a Databricks account, governance stays with the provider. What changed is the set of things you can put in a share, and that set now includes data you have not brought in yet.
We would still copy anything that gets read constantly or joined heavily. Federation is a query-time hop, and a hop over someone else's warehouse under load is where this gets slow. The new capability is best for the tables you share because you have to, not the ones you share because they are hot.
Update, 23 September 2026 #
On 22 September Databricks added email invitations to OpenSharing, in beta. Instead of exchanging a sharing identifier or a credential file with the recipient, you enter their email address and Databricks sends them a secure activation link that connects them to the shared data (release notes).
On its own that's a convenience. Read next to the foreign sharing changes this note covers, it's the other half of a pattern. Putting a federated table in a share got easier last week, and now putting a person on the other end of that share takes an email address and no coordination with their platform team. The friction that used to slow a share down, the credential file someone had to hand over carefully, was also the step where somebody thought about what they were sending and to whom.
So the position tightens. We still say use foreign sharing to retire pipelines that exist only to feed a share, and we still say watch the provider-side materialisation cost for a full billing cycle. Add one thing: decide who in your organisation is allowed to send an activation email before anyone discovers they can. Recipients created this way read data that costs you compute when they scan it, and a share that takes thirty seconds to set up will get set up thirty seconds after someone asks for it.