Data Sharing and Federation
Sharing versus federation
These are different problems and questions deliberately mix them. Delta Sharing moves data out to a recipient who reads it with the Delta Sharing protocol (open sharing, any client) or Databricks-to-Databricks sharing (Unity Catalog to Unity Catalog, no token handling by the user). Lakehouse Federation reads data in place from an external system - you create a connection (with a secret or OAuth), then a foreign catalog, and query foreign tables locally without copying data.
Delta Sharing specifics
Objects are shared via a share to a recipient. Only Delta-format tables, views, materialised views, and volumes (as applicable) can be shared - a non-Delta table must be converted first. Partition filtering restricts which partitions a recipient sees, and column/row-level security can be applied through dynamic views before sharing. Recipients get read-only access; the provider's audit logs and system.access.audit record share access. Open-sharing recipients authenticate with a bearer token or activation link; rotate and revoke credentials rather than re-sharing.
Federation traps
Foreign catalogs are read-only - no writes, no MERGE. Predicate and projection pushdown varies by data source; a question showing a slow federated join usually expects "the join/filter did not push down, so data was pulled locally". Federation also inherits the source's performance; it is not a substitute for ETL when you need repeated heavy joins.
Rule of thumb: share when the consumer should see a curated, read-only slice of your lakehouse; federate when you want ad-hoc reads of someone else's operational system without ingesting it.