Delta Sharing in Databricks — What, Why, and How (Provider & Recipient)

---

TL;DR

Delta Sharing lets you share live, governed data from Unity Catalog with other teams or external partners without copying it. You create a share, add data assets to it (tables, views, streaming tables, volumes, materialized views, even models/notebooks), create a recipient, and grant access. Recipients can query the data from their own Databricks workspace (Databricks‑to‑Databricks) or any platform that supports the open protocol.

---

Key concepts

• Provider: You — the team who owns the data and shares it.
• Share: A UC securable that contains the assets you expose (and optional partitions/aliases).
• Recipient: A named identity (partner, workspace, app) that consumes a share.
• Two sharing modes:
  1. Databricks‑to‑Databricks → recipients create a catalog from your share and query it like regular UC tables.
  2. Open Sharing → recipients outside Databricks read via the Delta Sharing client using an activation URL / profile (OIDC‑based federation or credential file).

---

What you can share (high level)

• Tables (full or partitioned)
• Streaming tables (read streams safely)
• Views (incl. dynamic views for row/column security)
• Materialized views
• Volumes (files)
• Models and Notebooks

Bonus: You can alias objects for cleaner names and filter partitions per‑recipient (for true multi‑tenant sharing).

---

Provider workflow (UI in 60 seconds)

1. Catalog → Delta Sharing → Shared by me → Share data
2. Name the share, add your data assets
3. Create/select recipients
4. Click Share data

That’s it. The rest is governance: restrict who can see the share, audit grants, and revoke when needed.

---

Data Sharing permissions (what the checkboxes mean)

These are metastore-level privileges you typically give to a small set of data‑sharing admins. They control who can create and manage Delta Sharing artifacts.

Permission	What it allows	Who usually gets it
CREATE CLEAN ROOM	Create/own clean rooms (privacy‑preserving collaboration spaces) and manage their contents.	A few platform admins / stewards.
CREATE PROVIDER	Register a provider object (represents your org as a publisher in Marketplace/Sharing).	Platform admins.
CREATE RECIPIENT	Create recipients (partners/workspaces/apps that will receive shares).	Sharing admins; sometimes project leads.
CREATE SHARE	Create shares and add tables/views/volumes to them.	Data stewards who own the datasets.
SET SHARE PERMISSION	Grant/revoke SELECT on a share to recipients; manage per‑recipient partitions.	Same as above; least‑privilege stewards.
USE MARKETPLACE ASSETS	Browse and use Marketplace listings shared to you.	Broad group (often all account users).
USE PROVIDER	View provider metadata and use it when creating catalogs from Marketplace/Sharing.	Sharing admins / recipients’ admins.
USE RECIPIENT	View/manage recipient metadata (e.g., fetch activation link).	Sharing admins.
USE SHARE	View share metadata (name, contents); needed to reference a share when automating.	Sharing admins.

Quick checks & grants

-- See who has what at the metastore
SHOW GRANTS ON METASTORE;
SHOW GRANTS TO `data_sharing_admins`;

-- Minimal set for a sharing admin group
GRANT CREATE SHARE, CREATE RECIPIENT, SET SHARE PERMISSION ON METASTORE TO `data_sharing_admins`;

-- Optional (if they also publish in Marketplace / manage providers & clean rooms)
GRANT CREATE PROVIDER, CREATE CLEAN ROOM ON METASTORE TO `data_sharing_admins`;

-- Let everyone browse Marketplace assets (typical default)
GRANT USE MARKETPLACE ASSETS ON METASTORE TO `account users`;

Remember: sharing admins also need normal data permissions (e.g., USE CATALOG/SCHEMA, SELECT on the source tables) to be able to add objects to a share.

Provider workflow (SQL you can paste)

Prereqs: You’re a metastore admin or have CREATE SHARE + rights on the source objects.

-- 1) Create a share
CREATE SHARE partner_sales COMMENT 'Curated sales for partners';

-- 2) Add assets (table + alias)
ALTER SHARE partner_sales ADD TABLE prod.gold.sales_daily AS sales_daily;

-- Optional: share only a partition (e.g., region)
ALTER SHARE partner_sales ADD TABLE prod.gold.sales_daily
  PARTITION (region = 'US');

-- Optional: allow history/streaming reads of a table
ALTER SHARE partner_sales ADD TABLE prod.gold.sales_daily WITH HISTORY;

-- 3) Create a recipient (Databricks-to-Databricks)
CREATE RECIPIENT acme_ws COMMENT 'ACME partner workspace';
-- Grab activation link/ID for the partner admin
DESCRIBE RECIPIENT acme_ws;

-- 4) Grant access
GRANT SELECT ON SHARE partner_sales TO RECIPIENT acme_ws;

-- 5) Inspect grants and contents
SHOW GRANTS ON SHARE partner_sales;     -- who has access
SHOW ALL IN SHARE partner_sales;        -- what’s inside

To revoke

REVOKE SELECT ON SHARE partner_sales FROM RECIPIENT acme_ws;

To update (examples)

ALTER SHARE partner_sales RENAME TO partner_sales_v2;
ALTER SHARE partner_sales REMOVE TABLE prod.gold.sales_daily;
COMMENT ON SHARE partner_sales IS 'FY25 scope';

---

Recipient workflow (Databricks‑to‑Databricks)

After the recipient activates the link:

-- Create a catalog from the provider’s share
CREATE CATALOG acme_partner USING SHARE provider_account.partner_sales;

-- Browse and query like normal
SHOW SCHEMAS IN acme_partner;
SELECT * FROM acme_partner.gold.sales_daily LIMIT 10;

Tip: Grant your own users/groups USE CATALOG/SCHEMA + SELECT on the received catalog just like any other UC catalog.

---

Recipient workflow (Open Sharing)

When the provider sends an activation URL (or profile), the recipient can use any platform that supports Delta Sharing. Minimal Python example:

# pip install delta-sharing
import delta_sharing as ds

profile_url = "https://<provider>/sharing/<activation>"   # or a local profile file
client = ds.SharingClient(profile_url)

# List tables in the share
for tbl in client.list_all_tables():
    print(tbl.name)

# Load a table into pandas
table_url = f"{profile_url}#partner_sales.gold.sales_daily"
import pandas as pd
pdf = ds.load_as_pandas(table_url)
print(pdf.head())

---

Partitioning & per‑recipient filters

You don’t have to create separate shares per customer. Use partitions and recipient properties so each recipient only sees their slice.

Example partition by property (sketch):

ALTER SHARE partner_sales ADD TABLE prod.gold.sales_daily
  PARTITION (account_id = CURRENT_RECIPIENT('databricks-account-id'));

---

Governance & security notes

• Only trusted admins should have CREATE SHARE / CREATE RECIPIENT.
• Recipients can only be granted SELECT on a share. Providers retain full control and can revoke anytime.
• Dynamic views + column masks continue to apply when shared, so you can enforce row/column‑level security.
• Use SHOW/DESCRIBE statements and the Delta Sharing UI to audit who has access and what is exposed.

---

Troubleshooting quickies

• Recipient can’t see data: Verify they created the catalog from the share (D2D), and that GRANT SELECT ON SHARE ... TO RECIPIENT ... was applied.
• Permission denied adding a table: The share owner must also have USE CATALOG/SCHEMA + SELECT on the source object.
• Schema changed upstream: Shares reflect the latest schema; recipients may need to refresh their metadata/bindings.

---

Repeatable automation (CLI/Terraform)

• CLI: databricks shares create|update|list, databricks recipients create|list, databricks shares update-permissions.
• IaC: Terraform resources databricks_share, databricks_recipient for fully automated provisioning.

---

Wrap‑up

Delta Sharing turns your lakehouse into a governed hub you can safely publish from and others can consume without ETL copies. Start with one curated table, grant a test recipient, and iterate toward partitioned, per‑tenant sharing.