Data Sharing on Databricks on AWS: OpenSharing, Marketplace, and Lakehouse Federation

Lessons 01 to 11 built and governed a lakehouse that holds your data. The moment a second organization needs to read that data, a partner, a customer, a subsidiary, a regulator, a paying subscriber, three different platform surfaces offer to help, and they are routinely confused with each other. OpenSharing (the product; the open protocol was called Delta Sharing until June 2026) hands a live view of selected tables to someone who is not you. Databricks Marketplace is a storefront that sits on top of that hand-off and adds discovery, approval and procurement. Lakehouse Federation does the opposite thing in the same vocabulary: it lets your SQL reach into somebody else's live database or catalog without copying a byte. Each is governed through Unity Catalog securables, each has its own AWS networking story, and each fails in a characteristic way.

The teaching rule for this lesson, and the sentence to keep when the syntax blurs: a share is a live pointer, a foreign catalog is a live dependency, a Marketplace listing is a storefront on the pointer, and only an ETL copy is a thing you own. Get that ordering right and every feature below lands in its place.

In this lesson you will:

• separate the three surfaces, OpenSharing, Marketplace, Lakehouse Federation, and route six realistic collaboration requests to the right one (and know when the right answer is a deliberate copy);
• apply the June 2026 rename correctly: product and docs say OpenSharing, the SQL surface still says CREATE SHARE / GRANT ... ON SHARE, the OSS client is still delta_sharing, and audit events still start deltaSharing*;
• build a share the way the October 2026 docs specify it: CREATE SHARE on the metastore, ALTER SHARE ... ADD TABLE ... WITH HISTORY, partition-parameterized with CURRENT_RECIPIENT(), CREATE RECIPIENT, GRANT SELECT ON SHARE, verified with SHOW GRANTS TO RECIPIENT;
• choose an authentication story on evidence, Databricks-to-Databricks (no artifact at all), OIDC federation (no Databricks-issued secret), or bearer token (one-time credential file, IP ACL, scheduled rotation), and explain the 2026-12-08 token cliff to whoever still depends on one;
• read the wire: pre-signed URL access versus directory-based cloud tokens, which assets are eligible for which, and why directory credentials hand a recipient the Delta log including not-yet-vacuumed deleted data;
• govern shares like any other Unity Catalog securable: who may create them, what SHOW GRANTS TO RECIPIENT answers, how immediate revocation works, and how to run a quarterly access review against system.access.audit;
• publish through Databricks Marketplace: instant vs request listings, Public Marketplace vs private exchange, the no-fee / no-cut provider economics, and the 10% Universal Commit Drawdown arithmetic;
• stand up Lakehouse Federation with CREATE CONNECTION and CREATE FOREIGN CATALOG, using secret() (or a UC service credential plus an AWS IAM role on RDS PostgreSQL), and say exactly what join pushdown pushes where;
• keep the two network problems apart: outbound sharing (SecureConnect, NCC private endpoints on the metastore, recipient IP ACLs) versus inbound federation (PrivateLink, same cloud only);
• place clean rooms, a Delta Sharing vs S3 cross-account Lake Formation vs ETL copies comparative verdict, three named AWS case studies, a sourced October 2026 update box, eight worked examples, five diagrams, four interactive checks and twelve practice questions.

---

1. Three surfaces, one question: how does data leave, or arrive, without moving?

1.1 The surface map

"OpenSharing is the secure data sharing platform in Databricks that lets you share data and AI assets with users outside your organization, regardless of whether they use Databricks. OpenSharing is also the basis for Databricks Marketplace, an open forum for exchanging data products, and Clean Rooms" (docs, What is OpenSharing?, AWS, accessed 2026-10). That sentence is the architecture in miniature: Marketplace and Clean Rooms are built on the sharing layer, which is why a lesson that covers all three starts with the share object and not the storefront.

Two boundaries worth fixing before any syntax appears:

• Workspaces on the same Unity Catalog metastore do not use OpenSharing at all: Unity Catalog already governs access across them. "Databricks-to-Databricks sharing between Unity Catalog metastores in the same account is always enabled"; sharing outside the account needs an account or metastore admin to tick "Allow OpenSharing with parties outside your organization" and set the default recipient token lifetime (same docs page).
• Federation is not sharing. Federation is your compute querying their database over JDBC (or scanning their object storage after a metadata crawl); nothing is granted to an external party, and nothing is shared out.

1.2 Worked example E1: routing six collaboration requests

Reading: four of six requests are sharing, one is federation, one is a copy. The most expensive mistake on that list is answering (4) with a share or (5) with a share: both "work" in a demo and both fail the actual requirement (a live dependency where a snapshot was wanted; a revocable pointer where an immutable artifact was wanted).

• 📚 Did you know? Databricks reports the protocol's adoption five years after its 2021 launch as "28,000+ data recipients and 33% of shares flowing across platforms via open connectors" (Databricks blog, Introducing OpenSharing: the Next Evolution of Delta Sharing for the Agentic Era, 2026-06-16). The cross-platform third is the number that matters for this course: a third of shares are consumed by something that is not Databricks, which is exactly why the open protocol, not a platform API, is the thing the Linux Foundation now hosts.

---

2. OpenSharing: the protocol, the product, and the June 2026 rename

2.1 Two layers, one name each

Delta Sharing launched in 2021 as a Delta Lake sub-project. On 2026-06-10 Databricks announced OpenSharing, "Hosted by the Linux Foundation … the next evolution of Delta Sharing" (Databricks press release, 2026-06-10), and the 2026-06-16 technical blog drew the layer cake explicitly: "OpenSharing exists at two layers. The open-source protocol, now hosted by the Linux Foundation, is the published spec… Databricks OpenSharing is the enterprise implementation of the open protocol, built on top of other Databricks features such as Unity Catalog for governance and audit logging, Marketplace for discoverability, and more."

Scope grew with the rename: from tabular data to Agent Skills, AI models and unstructured data, plus Iceberg REST catalog (IRC) clients and on-premises storage partners, so "customers can now connect their on-premises assets directly to cloud platforms with no data movement" (press release, 2026-06-10).

2.2 Half-stale, half-live: the vocabulary table you will actually need

For this course: say OpenSharing for the product, Delta Sharing only when you mean the protocol lineage, the client libraries or the audit event names, and never trust an old tutorial's UI path.

2.3 The three sharing models

2.4 Unity Catalog: required, and not required: the verified nuance

The docs answer this as a FAQ, verbatim: "No, you do not need Unity Catalog to share (as a provider) or consume shared data (as a recipient). However, Unity Catalog provides benefits such as support for non-tabular and AI asset sharing, out-of-the-box governance, simplicity, and query performance" (docs, What is OpenSharing?, accessed 2026-10). Decomposed, because both extremes are exam-wrong:

1. Databricks-hosted sharing requires UC in practice: a share is a UC securable, recipients are UC securables, and setup means "Enable OpenSharing on a Unity Catalog metastore".
2. The OSS OpenSharing server can be run by anyone, on any platform, without Databricks; that is the customer-managed implementation path, and it is what makes "you don't need UC" true in the general.
3. Recipients never need UC in Databricks-to-Open.
4. Databricks-to-Databricks needs a UC metastore on both sides.
5. Workspaces on the same UC metastore don't use OpenSharing at all.

---

3. A share is a Unity Catalog securable

3.1 The object and its privileges

"A share is a securable object in Unity Catalog that represents a collection of data and AI assets you want to share with one or more recipients" (docs, Create shares for OpenSharing, footer 2026-10-09). Three rules follow, and each one has broken a live integration:

• Creating a share needs CREATE SHARE on the metastore. The docs recommend owning shares as a group, not a person: people leave, groups don't.
• Adding assets requires share ownership plus USE CATALOG + USE SCHEMA + SELECT on each asset. The docs' warning is explicit: "You must keep that privilege in order for the asset to continue to be shared. If you lose it, the recipient cannot access the asset through the share." Ownership transfers, group restructures and grant clean-ups all break live shares this way.
• Delegating uses USE SHARE + SET SHARE PERMISSION on the share; the recipient side needs USE RECIPIENT (or recipient ownership), and Marketplace approval flows additionally need CREATE RECIPIENT / USE RECIPIENT. One share can contain assets from only one Unity Catalog metastore.

3.2 What can go in a share (verified Oct 2026 list)

Tables and table partitions (yes, PARTITION(...) and CURRENT_RECIPIENT() property-based partitions), whole schemas (ADD SCHEMA, which grants future assets too), views including dynamic views (the row/column restriction mechanism for open recipients), materialized views, metric views, streaming tables, managed Iceberg tables, foreign Iceberg tables, foreign Delta tables, foreign schemas and tables, volumes, Python UDFs, notebooks, AI models, Genie Agents, and FeatureSpecs, the shareable-asset list on the create-share page (docs, 2026-10-09). What does not ride along for free: table/column comments and primary-key constraints only flow for Databricks-to-Databricks shares shared on or after 2024-07-25; older grants must be revoked and re-granted.

3.3 The history flags decide what recipients can do

The trap in the last two rows: the "cheapest" configuration (WITHOUT HISTORY, or a partition-filtered share) silently disables recipient time travel, streaming and CDF, and also disqualifies the fast cloud-token path. "WITHOUT HISTORY is fine" is a decision to re-make every time the recipient's requirements change.

3.4 Worked example E2: the provider builds a share (real SQL, as of Oct 2026)

Numbers as of Oct 2026: WITH HISTORY default requires DBR 16.2+; both history flags need 12.2 LTS+; ADD SCHEMA needs 13.3 LTS+ or a SQL warehouse; the share contains assets from one metastore; revocation later is a single REVOKE because the recipient never held the data.

---

4. Recipients: five authentication types, three stories

4.1 The authentication_type enum

CREATE RECIPIENT yields an object whose authentication_type is one of DATABRICKS, TOKEN, EMAIL (Beta; wraps a DATABRICKS or TOKEN child and requires an account admin to enable OpenSharing-by-email from the account console Previews page), OAUTH_CLIENT_CREDENTIALS, or OIDC_FEDERATION (docs, Manage data recipients, 2026-06-23). Recipients also carry IP access lists, activation status, token lifetime, and, for OIDC, the IdP endpoint plus mTLS endpoint. SHOW GRANTS TO RECIPIENT lists the shares a recipient can read.

4.2 Worked example E3: Databricks-to-Databricks, the zero-artifact flow

Access persists "as long as the underlying token is valid and the provider continues to share the data" (docs, 2026-07-13): in this model there is no token, so it persists exactly as long as you keep the grant. Recipients "can read and make copies of the shared data, but… can't modify the source data."

4.3 Worked example E4, Databricks-to-Open: bearer token, then the client side

4.4 OIDC federation: the flow where Databricks issues no secret at all

"This authentication flow uses OIDC federation, allowing JSON Web Tokens (JWTs) issued by the recipient's IdP as short-lived OAuth tokens authenticated by Databricks… Databricks does not generate or manage any tokens or credentials. Instead, the recipient's IdP generates a JWT containing identity claims" (docs, Enable OIDC federation for OpenSharing recipients, accessed 2026-10). The provider writes a federation policy against the recipient's IdP, policy name, issuer URL, subject claim (oid / groups / azp in Entra ID), subject, audiences, and Databricks returns a portal URL. The recipient downloads an oauth_config.share profile and feeds it to the open client:

Two documented flows: U2M (Power BI / Tableau via the OAuth Authorization Code Grant against Databricks' multi-tenant Entra app 64978f70-f6a6-4204-a29e-87d74bfea138, one-time tenant-admin consent) and M2M (OAuth Client Credentials with a service principal registered in the recipient's IdP: the Python/Spark path). "No secrets or credentials are exchanged between Databricks, the provider, or the recipient. All secret management remains internal to each organization." Grants still use the same GRANT... ON SHARE SQL.

The posture ladder, in order: Databricks recipient → Databricks-to-Databricks (no artifact); non-Databricks partner → OIDC federation (no Databricks-issued secret); only when the recipient has no usable IdP → token + IP ACL + scheduled rotation, and check the 2026-12-08 cliff before you build on any token minted before 2025-12-08.

• 📚 Did you know? Three facts about bearer credentials that surprise people: the credential file "can be downloaded only one time", lose it and you re-issue the recipient object, not the file; the provider must "configure the default recipient token lifetime when they enable OpenSharing for your Unity Catalog metastore", so an org-wide default exists before any individual recipient does; and there is also OIDC federation for Iceberg REST recipients, delivered through a profile-generation portal link, the same no-Databricks-issued-secret posture, pointed at an Iceberg REST client instead of the tabular client (docs, accessed 2026-10).

---

5. How the bytes actually move: pre-signed URLs vs cloud tokens

5.1 Two access modes on the wire

Views, materialized views, streaming tables, volumes, notebooks, UDFs and models are explicitly not cloud-token eligible, so they are delivered by materialization: the provider setup page documents the TTL of data materialization, "By default, the TTL is eight hours. The cache itself will be evicted by materialization after an additional three hours", and every materialization lands in the system.sharing.materialization_history table (365-day retention). Materializations occur "when a recipient queries shared dynamic views, materialized views, streaming tables, and foreign tables."

5.2 The Delta-log exposure: the privacy surprise in directory mode

The create-share docs state that cloud-token credentials are scoped to the table's root directory: data files and the Delta log, which "contains the commit history for each table version, information about the committer, and deleted data that has not been vacuumed." Two consequences you must design around:

1. A recipient with directory access can see more than "the current rows"; they can see the provider's un-vacuumed past, up to the VACUUM retention window (data files: 7 days by default; the log itself: 30 days via delta.logRetentionDuration, docs.delta.io, accessed 2026-10).
2. If your privacy story assumed "they only see what the view shows", use pre-signed URL access, share a dynamic view instead of the base table, or clean up with VACUUM before the share goes out: not after.

5.3 Worked example E5: reading the wire from the audit trail

Reading: the mode mix in this query is itself a security signal. A recipient you intended to be on pre-signed URLs suddenly appearing in generateTemporaryTableCredential means their share's eligibility changed (history flag added, partition filter removed); which may be exactly what you configured, or exactly what you didn't.

---

6. Governing shares: grants, audit, revocation, and the live-pointer trap

6.1 The privilege model, compressed

Revocation is instant and total because of the sentence that underpins the whole model: the recipient never held the data, only the right to read it. That is the property ETL copies cannot offer, and the reason a share beats a bucket policy whenever "we may need to take this back" is a real requirement.

6.2 Worked example E6: the quarterly access review

6.3 ⚠️ WARNING: a share is a LIVE POINTER, and VACUUM is pointed at your recipients

Design rules that fall out: (1) never point a WITH HISTORY share at a table anyone VACUUMs on a short timer without agreeing the retention window; (2) prefer sharing views (including dynamic views with CURRENT_RECIPIENT() row logic) when the recipient's contract is narrower than the base table; (3) treat the recipient's read path as a production dependency of your table's lifecycle operations: the same discipline you would apply to a downstream job you don't control, because that is exactly what it is.

---

7. Databricks Marketplace: the storefront on top of the share

7.1 Listing anatomy

A listing points at a share. Two access choices, fixed at creation: "Data assets are instantly accessible" versus "Consumers must request access to the listing". Two publish targets: Public Marketplace or a Private exchange. Asset types: tables · files (Volumes) · models · notebooks · MCP servers: plus apps since June 2026 (Public Preview). The wizard lets you attach up to 10 sample notebooks per listing.

Fulfillment is the sharing layer doing what it already does: "If the consumer is on a Unity-Catalog-enabled Databricks workspace, they gain access to that share as a catalog in their Databricks workspace in near-real time. If the consumer is not on a Unity-Catalog-enabled Databricks workspace, a credential file is generated and made available for them to download" (docs, 2026-06-23).

7.2 Becoming a provider, and the policies that gate you

"To be a private-exchange-only provider, you can sign up using the provider console. To create public listings, you apply through the Databricks Data Partner Program" (docs, 2026-04-09). After approval you "must grant at least one user the Marketplace admin role", a Databricks account admin grants it, and approval-required listings additionally need CREATE RECIPIENT / USE RECIPIENT. The provider policies page (2023-10-10) is short and absolute: every listing must state update frequency and provider/consumer terms of use, and "if your Product includes Personal Data, you must be legally authorized to share such Personal Data. However, a Product must never include Sensitive Personal Data."

7.3 The money: no cut, and a 10% commit drawdown

• Listing economics: "There is no fee for providers to list their assets on Databricks Marketplace. We host both free and paid listings, but we don't take a cut of the revenue that providers receive. Transactions for paid listings happen between consumers and providers directly" (Databricks blog, Top 10 Marketplace Questions, Answered, 2024-11-11).
• Procurement economics (new, June 2026): the Universal Commit Drawdown program lets consumers use "up to 10% of their Universal Commits to purchase eligible third-party partner products through the Databricks Marketplace" (docs, accessed 2026-10). Conditions: the contract "must be signed after June 15, 2026"; the invoice is "no more than 45 days old" and "denominated in USD"; the partner "validates the transaction within 10 business days"; and "There are no transaction fees" on this path. The docs' own arithmetic: "$50M Universal Commit = up to$5M in Marketplace drawdown."
• Still roadmap, not GA: in-platform transactability, pre-paid spend as checkout, "minus a small (industry-standard) fee", was announced for "later in 2026" (blog, 2026-06-17). No percentage is published; do not model a fee you cannot cite.

7.4 Worked example E7: listing runbook and the drawdown arithmetic

Hover a bar: the cap is linear and hard: 10% of the Universal Commit, the full 10% available from day one of the commit, contract signed after 2026-06-15, invoice ≤ 45 days old, partner validates in 10 business days, no transaction fees on the invoice path. The docs' own worked figure is the third bar: a $50M Universal Commit equals up to $5M in Marketplace drawdown.

• 📚 Did you know? Marketplace has two procurement stories that people conflate. The drawdown path is invoice-based and fee-free today; the transactability path (in-platform checkout against pre-paid spend, "minus a small industry-standard fee") was announced 2026-06-17 for "later in 2026" and is a roadmap item: model the first, do not budget the second. Meanwhile Apps on Databricks Marketplace are Public Preview (2026-06-16): provider apps ship as closed-source containers, consumer-controlled egress is governed by the workspace's Serverless Egress Gateway policy, and each app runs on dedicated serverless compute.

---

8. Lakehouse Federation: querying in without moving

8.1 Two flavors, three securables

Lakehouse Federation is read-only queries over a live external system, expressed through three Unity Catalog objects: a connection ("a securable object in Unity Catalog that specifies a path and credentials for accessing an external database system"), a foreign catalog ("a securable object in Unity Catalog that mirrors a database in an external data system, enabling you to perform read-only queries"), and ordinary grants on that foreign catalog "at the catalog, schema, or table level as you would do with regular securables" (docs, accessed 2026-06-16 / 2026-06-29).

"Databricks keeps the definition of the catalog's schemas and their relations in sync with the foreign source": a foreign catalog is a live, read-only mirror of metadata, not a snapshot. Every query hits the source; there is no caching layer unless you build one (CREATE TABLE AS SELECT into a Delta table).

8.2 The verified October 2026 source lists: teach them as lists

Query federation (11):

• MySQL
• PostgreSQL
• Teradata
• Oracle
• Amazon Redshift
• Salesforce Data 360
• Snowflake
• Microsoft SQL Server
• Azure Synapse (SQL Data Warehouse)
• Google BigQuery
• Databricks

Catalog federation (7):

• Legacy Databricks Hive metastore
• External Hive metastore
• AWS Glue metastore
• Salesforce Data 360
• Snowflake
• Palantir Foundry
• Workday Data Connect

Three exam-grade observations, each from the lists themselves: Amazon Athena appears in neither: do not teach Athena federation; AWS Glue is a catalog-federation source, not a query-federation source; and Amazon Redshift is in query federation while the Redshift page carries its own restriction that "You cannot run federated queries on Amazon Redshift external data." CREATE CONNECTION supports exactly 8 TYPE values: DATABRICKS, HTTP, MYSQL, POSTGRESQL, REDSHIFT, SNOWFLAKE, SQLDW, SQLSERVER.

8.3 Worked example E8: federated PostgreSQL catalog (real DDL, AWS)

AWS-native variant (verified): "Run federated queries on Amazon RDS for PostgreSQL (IAM authentication)" is "available on Databricks on AWS only, because it relies on an AWS IAM role referenced by a service credential"; it requires DBR 18 LTS or above and Standard or Dedicated access mode, one IAM role in the RDS account with a self-assuming trust policy carrying the service credential's external ID, and the connection adds aws_region '<region>' plus credential '<service-credential-name>' instead of a password (docs, 2026-08-19). Snowflake additionally supports OAuth (client_id, client_secret).

8.4 Pushdown semantics: what actually happens to your SQL

Queries run on Databricks compute (SQL warehouse or cluster). Predicates, projections, joins and aggregates are pushed down to the foreign source where the connector supports it, and only the needed rows come back. Join pushdown is supported by "Oracle, PostgreSQL, MySQL, SQL Server, Teradata, Redshift, Snowflake, BigQuery", and "This feature is Generally Available and enabled by default for Redshift, Snowflake, and BigQuery" (docs, 2026-03-26). Catalog federation pushes nothing of the sort: the scan happens in Databricks against S3. Consequences: federation latency = source-side query latency + transfer; a slow or down source means slow or down queries in Databricks; and a federated catalog is a live dependency, not a snapshot.

8.5 Networking: two problems that look alike and are not

"Private Link (only when the external database is on the same cloud as Databricks compute)" (docs, Networking recommendations for Lakehouse Federation, accessed 2026-10).

Solving one does not solve the other. A PrivateLink between your workspace and RDS does nothing for a recipient hitting your S3 bucket firewall; a SecureConnect proxy does nothing for your federated Postgres connection.

• 📚 Did you know? Federation credentials have exactly three documented homes, and only one of them is AWS-idiomatic: the secret('<scope>','<key>') function inside CREATE CONNECTION ("We recommend that you use Databricks secrets instead of plaintext strings for sensitive values"); a Unity Catalog service credential pointing at an AWS IAM role for RDS PostgreSQL IAM auth (DBR 18 LTS+, Standard/Dedicated, AWS-only); and: for Snowflake: OAuth with client_id / client_secret. Never a literal password in a notebook, a query history entry, system.access.audit.request_params or Terraform state. Also worth knowing: CREATE CONNECTION is the Lakehouse Federation API; ingestion connections are a different API (databricks connections create, the Lakeflow Connect family): same word, different product.

---

9. Clean rooms in one page

Databricks Clean Rooms is "a Databricks feature that uses OpenSharing and serverless compute to provide a secure and privacy-protecting environment where multiple parties can work together on sensitive enterprise data without direct access to each other's data" (docs, 2026-10-08): a consumer of the sharing layer, not a separate protocol. Each party holds a clean room securable in their own UC metastore, plus a Databricks-managed central ephemeral environment where the computation runs; assets arrive via OpenSharing under aliases; collaborators see column names and types but not each other's rows.

The honest teaching point: the privacy guarantee rests on human notebook approval, not a mathematical bound. Approving code you have not read is the failure mode, and it is the only one the platform cannot catch for you.

---

10. The traps this lesson will not let you keep

1. "Delta Sharing" as if nothing changed. June 2026: product and docs are OpenSharing; the SQL, the OSS client and the audit events keep the old names. Old tutorials also have the UI path wrong.
2. Believing a share is a copy. It is a live pointer (Section 6.3): deletes propagate, VACUUM breaks recipients, schema changes arrive ungated, directory tokens expose the un-vacuumed Delta log.
3. Assuming WITHOUT HISTORY is "fine". No time travel, no streaming, no CDF, no cloud-token fast path: the cheapest share configuration silently disables most recipient features.
4. Sharing a whole schema and expecting UC row/column filters to hold. Recipient-side restriction is dynamic views + CURRENT_RECIPIENT() or partition filters; tables carrying UC row filters, column masks or ABAC are excluded from schema shares.
5. Losing SELECT on the source. "You must keep that privilege": grant clean-ups, ownership transfers and team re-orgs all break live shares this way.
6. Treating a bearer credential file as a casual attachment. One-time download, bearer secret, IP-ACL-able, rotatable, and if it leaks, the holder reads everything the share grants until you revoke. Prefer D2D > OIDC > token.
7. Missing the 2026-12-08 token cliff. Tokens minted before 2025-12-08 with long or no expiry stop working that day.
8. Expecting federation to be a copy or a cache. A foreign catalog is a live read-only metadata mirror; latency is source latency; build a Delta table if you need a snapshot.
9. Putting federation passwords in the connection SQL as literals. They end up in query history, audit request_params and Terraform state. Use secret() or a UC service credential + IAM role.
10. Assuming Athena can be federated because it is AWS. The Oct 2026 lists contain no Athena entry; Glue is catalog federation; Redshift is query federation with its own external-data restriction.
11. Confusing federation networking with sharing networking. Inbound PrivateLink (same cloud) vs outbound SecureConnect/NCC/IP ACLs: solving one does not solve the other.
12. Thinking Marketplace takes a revenue cut. It doesn't for listings or paid-listing transactions, and the drawdown path carries no transaction fees; the announced "small fee" belongs to a future transactability feature.
13. Confusing a private listing with a private exchange. A private listing is invisible outside its exchange; a private exchange is a member-gated storefront whose members are Databricks customers with UC metastores. Neither replaces OpenSharing to a non-Databricks partner.
14. Over-trusting clean rooms. ≤10 collaborators, immutable names, locked membership, any deletion voids the room, and the privacy guarantee is human notebook approval.

---

Comparative Verdict: OpenSharing (Delta Sharing) vs S3 cross-account + Lake Formation vs ETL copies (AWS, as of Oct 2026)

• OpenSharing / Delta Sharing: the open, zero-copy, revocable pointer. The only option here that is an open protocol (Linux Foundation since 2026-06-10) with clients that work off-platform: 33% of shares already flow across platforms (blog, 2026-06-16). Zero copy, immediate revocation (the recipient never held the data, only the right to read it), the richest asset set on Databricks-to-Databricks (views, volumes, models, notebooks), and no egress cost for same-region reads. The price of that power is the live-pointer contract of Section 6: your VACUUM policy, your deletes and your schema changes are now somebody else's incident. Choose it when the recipient must not be on your platform, when revocability beats a guaranteed offline snapshot, and when "one grant, no delivery job to fail" beats a landing zone.
• S3 cross-account + AWS Lake Formation, the AWS-native grant, inside the AWS bubble. Lake Formation "uses the AWS Resource Access Manager (AWS RAM) to share the resource"; same-organization shares apply immediately, out-of-organization shares need an invitation; LF-TBAC is the recommended grant method; and "Integrated services such as Athena and Amazon Redshift Spectrum require resource links" (AWS docs, accessed 2026-10). You get row/column/cell granularity, LF-Tag attribute scaling and $0 permissions, but the consumer needs an AWS account, the catalog is Glue, and nothing here reaches a Power BI shop that has never heard of IAM. Choose it inside the AWS perimeter, when the consumers are your own accounts or partners who live in AWS anyway.
• ETL copies, the thing you own, and the thing you lose track of. Extracts work with absolutely everyone (including the air-gapped regulator in E1-5), give the consumer a stable ownable snapshot, and survive your outages. But the extract cannot be revoked, nobody knows who still holds it, you pay twice (build + reconcile), and staleness is baked in. Choose it deliberately, with an expiry date and an owner, never by default.
• Side note: Snowflake Secure Data Sharing is equally zero-copy and equally closed: "Data sharing is only supported between Snowflake accounts"; anything else means the provider owns a reader account (≤ 75 by default, dropped ones count for 7 days) and pays its warehouse credits (Snowflake docs, accessed 2026-10).
• Verdict in one line: Databricks recipient → Databricks-to-Databricks; non-Databricks partner → OpenSharing with OIDC (token only if forced); same-AWS-estate consumers → Lake Formation cross-account; nobody online and a regulator wants a file → an ETL copy, deliberately, with an expiry date.

---

2026 Updates (as of October 2026)

---

Real-World Case Studies

📋 Case A: Block (Square, Cash App, TIDAL) (financial services, Cloud: AWS) Challenge. 12PB of graph and analytics data fragmented across business units, plus a painful two-step IAM flow, attach IAM policies to roles, then to S3 buckets, that made cross-team access a ticket queue. Stack on AWS. Databricks, Delta Lake, Unity Catalog, Spark Declarative Pipelines, Delta Sharing (with clean rooms planned), S3 as co-located storage: Cloud: AWS on the story page (https://www.databricks.com/customers/block/unity-catalog, undated page, accessed 2026-10). Reported outcome. "12X Reduction in compute cost · 20% Reduction in data egress cost · 12PB Of data managed and governed", ~70 teams, 500 active power users, and data-sharing permission time cut "from days to seconds" (same URL, undated, accessed 2026-10). Quote. "Introduction to Databricks coincided with the launch of Unity Catalog, eliminating the need for evaluating alternative data governance tools.": Joseph Kesting (same URL). Maps to this lesson. Sections 6 and 9: "days to seconds" is precisely the delta between an IAM/S3 permission queue and a GRANT... ON SHARE on a UC securable, and the planned clean rooms are Section 9's notebook-approval model at a scale where 12PB cannot physically move. ⏳ Temporal note: undated page, accessed Oct 2026: treat every figure as what Block reported, not a platform guarantee.

📋 Case B: nCino (banking software, Cloud: AWS) Challenge. Consolidating 13 years of banking data and "trillions in loan history" while keeping compliance posture tight and sensitive financial information under full control. Stack on AWS. Databricks on AWS, Unity Catalog, AI/BI Genie: Cloud: AWS on the story page; use cases explicitly list Analytics and BI, AI, Data Warehousing, Governance and Security (https://www.databricks.com/customers/ncino, undated page, accessed 2026-10). Quote. "Keeping data within a single AWS ecosystem reduces complexity, strengthens compliance and gives teams full control over sensitive financial information." (same URL). Maps to this lesson. Section 1: nCino is the counter-case that makes the surface map honest: when the compliance argument is "stay inside one AWS account boundary", the answer is Lakehouse Federation (Section 8) for outside databases and Lake Formation-style grants for inside accounts, not an external share. Knowing when not to share is part of the design. ⏳ Temporal note: undated page, accessed Oct 2026.

📋 Case C: Atlassian, and the protocol's named adopters (software, multi-industry) Challenge. Unlocking access to critical cloud data for customers who are not all on one platform: the exact cross-platform problem an open protocol exists to solve. Evidence. Databricks' OpenSharing press release (2026-06-10) names Amadeus, Atlassian, LSEG, SAP, Stripe and The Trade Desk as users of the standard (https://www.databricks.com/company/newsroom/press-releases/databricks-announces-opensharing, 2026-06-10); the product page (accessed 2026-10) additionally names Shell, Nasdaq, Deutsche Börse, SafeGraph and YipitData. Atlassian: "Atlassian Analytics launched data shares, leveraging OpenSharing from Databricks, to unlock access to critical cloud data for our customers at scale" (opensharing.io, accessed 2026-10). Maps to this lesson. Section 2; these are the names attached to the "33% of shares flowing across platforms" statistic, and they are why the protocol (Linux Foundation) rather than the product API is the durable thing to design against. ⏳ Temporal note: adoption claims are vendor-reported as of the 2026-06 announcements.

---

---

Practice Questions

Hover a bar: WITHOUT HISTORY leaves only basic batch reads (1); adding history but a partition filter recovers time travel but still blocks cloud-token access (2); full WITH HISTORY with no partition filter unlocks pre-signed-URL reads plus time travel, CDF and streaming (4); the same share additionally becomes directory-based cloud-token eligible (5): with the Delta-log exposure that Section 5.2 and the ⚠️ WARNING attach to that mode. The scale is a teaching model of the documented feature matrix, not a platform metric.