Delta Sharing is an open protocol that lets Engage share live datasets securely with external recipients without copying data. Recipients connect with standard tools (Spark, pandas, Power BI, Tableau, etc.) using a small credential file or OIDC federation and can query data in real time. It’s read‑only by design.

How Delta Sharing works

Delta Sharing is an open, REST‑based protocol for secure, real‑time data exchange on top of cloud storage (S3/ADLS/GCS). Providers (Voyado) expose shares that contain tables; recipients connect using a credential profile (or OIDC) with Delta‑Sharing‑compatible tools. No replication is required, the consumer just reads data from the provider’s storage through signed URLs.

There are two common modes but Voyado provides only one:

Open sharing (most common for non‑Databricks recipients). Here you send an activation link so the recipient can download a credential file (.share) or use OIDC. They then connect from Spark/pandas/BI tools.

Shares and Recipients

Share: A named container of assets to expose, typically one or more Delta tables in a UC metastore, organized into schemas. You grant one or more recipients access to a share (one data product per share).

Recipient: The external party (company, workspace, service principal, or app) that is allowed to read from the share. For open sharing, you generate an activation link and credentials (or OIDC config). For Databricks‑to‑Databricks, you identify the recipient by metastore ID.

Example:

• Share: Engage Data
• Schemas/Tables: contactslatest
• Recipient: Marketing

Data Products in Delta Sharing

A data product is a logically grouped set of datasets (tables) delivered together to solve a business use case. We publish each data product via one share to keep ownership, lineage, policies, and SLAs clear. This improves discoverability (“what’s in the share?”) and governance.

Naming suggestions:

• Share name: The available data product
• Recipient name: A descriptive name to whom or what is used for. E.g helena or marketing.

Architecture

One share per data product is recommended. It keeps lifecycle/versioning simple (deprecate v1, publish v2) and keeps permissions isolated.

One recipient per share is also strongly recommended. It offers easier auditing and revocation, and avoids role sprawl. You can create multiple recipients when the same data product goes to different partners or environments.

Under the hood, connectors read through the Delta Sharing server with short‑lived links to storage; that’s how we achieve real‑time access without copying data.

Common recipient use cases

Real‑time analytics in BI: Power BI Desktop connects with the Delta Sharing connector; analysts build reports on live data and schedule refreshes in the service.

Data science / notebooks: Data scientists load tables to pandas or Spark for feature engineering or model training.

Cross‑cloud collaboration: Partners on any cloud access shared tables without us copying data across clouds.

Incremental ingestion: Consumers pull Change Data Feed (CDF) from a shared table for efficient downstream loads. (Provider must enable “history sharing”.)

Creating share and recipient in Config Hub

Here are the steps to follow to create a Delta Share share and recipient.

1 - Start the Share creation

Navigate to the Delta Share section of Config Hub and select "Create share" to begin.

2. Select Data Product

Choose the specific Data Product you want to share from the available options.

3. Configure Recipient access

Enter the name of the recipient who will have access to this Share.

4. Complete Share Creation

Click "Create" to finalize the setup then wait approximately 20 minutes.

5. Activate Recipient Access

Copy the generated URL from the interface then visit the link to activate the recipient's access.

Implementation details

More detailed information for implementing Delta Sharing can be found on the developer site.
 

Article last reviewed 20 March 2026 12:34