Question 1

A partner needs your daily aggregates and proposes an SFTP drop of CSVs. Make the case for Delta Sharing instead.

Accepted Answer

The recipient reads your existing Delta table directly from your storage through the sharing protocol, so there is no copy, no export job, and revocation is immediate. With a file drop you build an export job, pay to write a second copy, and the partner's data is only as fresh as the last run. Delta Sharing removes the copy: you create a share, add the table, create a recipient, and grant SELECT on the share. When the recipient queries, the sharing server checks their permission and returns short-lived pre-signed URLs, and their client reads the Parquet directly from your object storage. The data they see is the live table, so there is no export schedule to go wrong. Revoking is a single grant change rather than chasing files that were already downloaded. It is an open protocol, so the recipient does not have to be a Databricks customer. No export job and no second copy of the data. The sharing server returns short-lived pre-signed URLs after a permission check. The recipient reads directly from your object storage, seeing live data. Revocation is a grant change, effective on the next request.

Question 2

One recipient is another Databricks account and another is a Python team with no Databricks at all. Does the setup differ?

Accepted Answer

Yes — Databricks-to-Databricks sharing uses the recipient's Unity Catalog sharing identifier and mounts as a catalog; open sharing issues a credential file for any client. For a Databricks recipient you create the recipient with their metastore's sharing identifier, which establishes a trusted relationship between the two Unity Catalogs. On their side the share appears as a catalog they can query with normal three-level names, and their reads carry their own identities, which makes auditing and onward governance much better. For a non-Databricks recipient you use open sharing: Databricks generates an activation link that yields a credential file containing a bearer token and endpoint, and any Delta Sharing client — the Python connector, pandas, Spark, a BI tool — can use it. The tradeoff is that the credential file is a secret you have handed out: anyone who holds it is the recipient, so it needs rotation and an expiry, and you lose per-user attribution on their side. D2D uses the recipient metastore's sharing identifier and mounts as a catalog. Open sharing issues a credential file usable by any Delta Sharing client. D2D preserves recipient-side identity for audit and onward grants. A credential file is a bearer secret and needs expiry and rotation.

Question 3

Legal asks how fast you can cut a recipient off at the end of a contract. What is the honest answer?

Accepted Answer

Revoking the grant stops the next metadata or URL request immediately, but pre-signed URLs already issued remain valid until they expire. Access is checked when the recipient asks the sharing server for a table's files, and the server responds with pre-signed URLs that are valid for a limited time. Revoke SELECT on the share and the next request is refused, so nothing new can be fetched. A query that was already in flight holds URLs that will keep working until they expire, which is a short window but not zero. So the honest answer is 'effective immediately for new access, with a bounded tail measured in the URL lifetime'. You can also delete the recipient entirely, which invalidates their credentials rather than just one share. What you cannot undo is anything they already read and stored on their side, which is a contractual control, not a technical one. Revoking stops the next request; it does not recall issued URLs. Pre-signed URLs stay valid for a short, bounded lifetime. Deleting the recipient invalidates their credentials entirely. Data already read and stored by the recipient is a contractual matter.

Question 4

Your cloud egress bill jumped after onboarding one recipient. Nothing about the table changed. Explain it.

Accepted Answer

The recipient reads directly from your object storage, so their scans are your egress — and a cross-region or cross-cloud recipient pulling full tables pays that at your expense. The no-copy property means the bytes move from your bucket to their compute, and your cloud provider charges you for that egress. A recipient in the same region and cloud is cheap; one in another region or another cloud is not, and a recipient that re-reads the full history on every run multiplies it. The usual cause is their job doing a full scan because they have no predicate on the partition or clustering columns, or because their orchestration refreshes from scratch nightly instead of reading the increment. Find it by correlating storage egress metrics with the recipient's read pattern in the audit records, then look at what their query is actually scanning. The fixes are cooperative: share a table laid out so their filters prune, share an aggregate instead of raw rows, or ask them to read incrementally through change data feed. Recipient reads are egress from your bucket, billed to you. Cross-region and cross-cloud recipients make that expensive. Full-history rescans are the usual multiplier. Fix by sharing a prunable or pre-aggregated table, or by incremental reads.

Question 5

A recipient wants to process only what changed since their last run rather than rescanning. What do you have to enable, and what does it cost you?

Accepted Answer

Add the table to the share WITH HISTORY and enable change data feed, which lets the recipient read versions or changes — at the cost of retaining history you would otherwise vacuum. By default a shared table gives the recipient the current snapshot. Sharing WITH HISTORY exposes previous versions, which is what lets their client read a range rather than the whole table, and with change data feed enabled on the table they can consume inserts, updates, and deletes directly. The cost is retention: the files backing those versions must still exist, so your VACUUM retention has to cover the window the recipient relies on, and that is extra storage. It also means the recipient can time travel across that window, which is a disclosure decision — they can see what a row looked like before you corrected it. Set the retention window deliberately and state it in the agreement, rather than discovering the mismatch when their incremental read fails because the files were vacuumed. ADD TABLE ... WITH HISTORY exposes previous versions to the recipient. Change data feed lets them consume row-level changes incrementally. Your VACUUM retention must cover their read window. History sharing also lets them see pre-correction values.

Question 6

Compliance asks for a monthly report of exactly which tables each recipient read and when. Where does that come from?

Accepted Answer

The system.access audit tables record Delta Sharing activity on the provider side, including the recipient, the share, and the object accessed. Because every read goes through the sharing server for permission and URL issuance, the provider sees each access and it is recorded in the audit tables under the system.access schema. You can group by recipient and shared object to produce exactly the report compliance wants, and you can spot patterns like a recipient pulling the whole table nightly. The limits are worth stating: the audit records recipient-level activity, so with open sharing you see the recipient, not which human on their side ran the query, whereas Databricks-to-Databricks sharing carries more identity detail. Audit tables also need their schema enabled on the metastore and have no backfill, so if this is a contractual requirement, enable it before the first contract rather than after the first audit. Build the report as a scheduled query over the audit tables and keep its output, so you are not dependent on audit retention. Provider-side system.access tables record sharing reads per recipient. Open sharing shows the recipient, not the individual on their side. Audit schemas must be enabled per metastore and do not backfill. Persist the monthly report so it outlives audit retention.

Question 7

A partner wants to measure audience overlap with you, but neither side will hand over customer identifiers. Is Delta Sharing the answer?

Accepted Answer

No — that is a clean room: approved code runs over both parties' inputs and only the agreed aggregate output comes back, with neither side reading the other's rows. Delta Sharing gives the recipient read access to rows you chose to share, which is exactly what both parties are refusing here. A clean room instead creates a collaboration environment where each side contributes tables, and only notebooks or queries both sides approve may run against them. The output is restricted to what was agreed — typically aggregates above a minimum count — so neither party can read the other's raw identifiers. The real design work is in the rules rather than the plumbing: what join key is permitted, what aggregation floor prevents re-identification of a small cohort, and who can approve a new piece of code. Treat it as a joint governance agreement with compute attached, not as a fancier share. Sharing grants read access; a clean room grants only approved computation. Both parties contribute inputs and approve the code that runs. Output is limited to the agreed aggregate, not raw rows. Aggregation floors are what stop re-identification of small cohorts.

Question 8

You are standing up data sharing as a product for forty external partners. What is the design, and what do you refuse to do?

Accepted Answer

A narrow versioned set of shared gold tables, one recipient per partner with expiry, D2D where possible, and per-recipient audit and egress monitoring — and no sharing of silver or raw. The technical pattern is straightforward: a dedicated publishing schema of contracted gold tables, one share per product and one recipient per partner so revocation and audit are per-partner, with recipient expiration set and credentials rotated for open sharing. The decisions that matter are editorial. You refuse to share silver or raw, because every shared table is an interface whose schema you can no longer change freely, and raw grain is where accidental disclosure lives. You version the shared tables so a breaking change is a new table rather than a surprise, and you state freshness and history retention in the contract because both are now obligations. Operationally you need per-recipient egress and read monitoring, since the provider pays for recipient scans, and a quarterly review that retires shares nobody has read. Without that review, you accumulate forty permanent interfaces and lose the ability to evolve your gold layer. One share per data product, one recipient per partner, with expiry set. Prefer D2D for identity-aware audit; rotate open-sharing credentials. Never share silver or raw — every shared table becomes a frozen interface. Monitor egress and reads per recipient, and retire unused shares quarterly.