Skip to main content
Select Databricks in the Inputs and/or Destination strip of the Job form. Both directions use Databricks-to-Databricks (D2D) Delta Sharing and require your workspace to be on Databricks Unity Catalog.
Databricks Delta Sharing lets a Job read its input set directly from your Unity Catalog and/or deliver its assembled output back into your Unity Catalog. Each direction is configured independently and uses opposite Delta Sharing roles:
DirectionYour roleNimble’s role
Input - share your table with NimbleProviderRecipient
Destination - mount Nimble’s outputRecipientProvider

​
Nimble’s global metastore ID

Both directions reference Nimble’s Unity Catalog metastore. Wherever the property tables below mention it, use: 
aws:us-east-1:2f3ba1b1-429c-491f-b37d-ebb46f22f3e9
This is a global metastore ID in the <cloud>:<region>:<uuid> form required by Databricks D2D sharing. The bare UUID is not enough.

​
Prerequisites

  • Databricks CLI v0.205+ authenticated against the workspace you want to share from / into. See the Databricks CLI install guide and databricks configure.
  • A metastore admin or a user with the CREATE RECIPIENT, CREATE SHARE, and CREATE CATALOG privileges on your UC metastore.

​
Input: share your table with Nimble

In this direction, you are the provider: you publish a Delta Sharing share whose recipient is Nimble’s metastore. On each Job run, the Job reads the current contents of the shared table.

​
Job form fields

Set these in the Job form under Inputs → Databricks:
FieldDescription
ProviderDelta Sharing provider name as it appears in Nimble’s metastore - Databricks D2D derives this on Nimble’s receiving side from your metastore identity. Your Nimble account contact can confirm the exact string if you’re unsure.
ShareShare name on your side (the value you pass to databricks shares create --name <...>).
SchemaSchema (database) inside the share that holds the table you want Nimble to read.
TableTable name inside that schema.

​
One-time setup

1

Create a recipient that points to Nimble's metastore

The recipient is the Databricks-side object that grants Nimble permission to receive your shares.
databricks recipients create --json '{
  "name": "nimble",
  "authentication_type": "DATABRICKS",
  "data_recipient_global_metastore_id": "aws:us-east-1:2f3ba1b1-429c-491f-b37d-ebb46f22f3e9",
  "comment": "Nimble Delta Sharing recipient"
}'
You only do this once - re-use the same recipient for every additional table you share with Nimble.
2

Create a share

Pick any name you like (e.g., nimble_inbox). The Job form’s Share field will use this value.
databricks shares create \
  --name nimble_inbox \
  --comment "Tables shared with Nimble"
3

Add the table to the share

Replace main.inbox.products with the fully-qualified UC name of the source table (<catalog>.<schema>.<table>). The shared_as value sets how the table appears on Nimble’s side - it must match the Schema and Table values in the Job form.
databricks shares update nimble_inbox --json '{
  "updates": [{
    "action": "ADD",
    "data_object": {
      "name": "main.inbox.products",
      "data_object_type": "TABLE",
      "shared_as": "inbox.products"
    }
  }]
}'
For partitioned tables or history sharing options, see the full SharedDataObject reference.
4

Grant the recipient SELECT on the share

databricks grants update share nimble_inbox --json '{
  "changes": [{
    "principal": "nimble",
    "add": ["SELECT"]
  }]
}'
Once this grant lands, the share becomes visible on Nimble’s metastore. No support ticket, no manual coordination - the next Job run picks up the share automatically.
Every Job run reads the latest contents of the shared table; you do not need to re-publish the share unless you change the table name or schema.

​
Adding more tables later

Only steps 3 and 4 need to repeat for each additional table. The recipient (step 1) and the share (step 2) are reused across tables - just ADD a new data_object and re-grant SELECT if you create a new share instead of extending the existing one.

​
Destination: deliver Job output to your Unity Catalog

In this direction, Nimble is the provider and you are the recipient. On the first Job run, Nimble makes the share available to your metastore (creating both the share and the recipient on demand, bound to your Metastore ID). You mount the share locally as a Unity Catalog catalog and query it like any other UC table.
Data retention: 14 days. Nimble guarantees the shared table stays queryable for at least two weeks after each successful Job run, but not longer. Beyond that window, the shared table is not guaranteed to remain available. If you need the data to persist - or want a frozen snapshot of every run - materialize it into a UC table you own. See Persisting the data.

​
Job form fields

Set these in the Job form under Destination → Databricks:
FieldDescription
Share nameShare name on Nimble’s side that the output table will be published to. Created on demand if it doesn’t already exist. Pick any value - it’s only visible to your account.
Recipient nameRecipient name on Nimble’s side that represents your workspace. Created on demand and bound to Metastore ID. Use one recipient per consuming metastore.
Metastore IDYour UC global metastore ID, in the form <cloud>:<region>:<uuid> (e.g. aws:us-east-1:a9e65c72-c515-45bc-a600-3048a46bd6a8). See “Finding your metastore ID” below.
Shared as<schema>.<table> alias for the shared table - the only name visible on your side. Pick a clean, stable value; renaming it later invalidates the catalog mount on your side.

​
Finding your metastore ID

Run one of the following inside the Databricks workspace that will consume the share: 
SELECT current_metastore();
The output is the value to enter in the Metastore ID field. The format is always <cloud>:<region>:<uuid> - the bare UUID returned by older Databricks endpoints is not accepted.

​
One-time setup (after the first Job run)

The share becomes available to your metastore after the Job’s first successful run. After that first run completes, run the following on your Databricks workspace:
1

Confirm Nimble shows up as a provider

Once Nimble has bound the recipient to your metastore, the share becomes visible in your UC metastore as a provider. List providers to find the exact name Databricks assigned it on your side:
databricks providers list --output json \
  | jq '.providers[] | select(.authentication_type=="DATABRICKS") | {name, recipient_profile_str}'
You can also do this in the UI: Catalog → Delta Sharing → Shared with me → Providers.
2

Inspect the share contents

Replace <provider_name> with the name from the previous step. Confirm the share you configured in the Job form is listed and contains a table named after your Shared as value.
databricks providers list-shares <provider_name>
3

Mount the share as a UC catalog

Pick any local catalog name (e.g., nimble). Once mounted, the Job’s output table is queryable as <catalog>.<shared_as>.
CREATE CATALOG IF NOT EXISTS nimble
USING SHARE `<provider_name>`.`<share_name>`;
<share_name> is the value entered in the Job form’s Share name field. <provider_name> is the value from step 1.
4

Grant usage to your team

The mount itself only grants access to the metastore admin who created it. Open it up to consumers with UC grants:
databricks grants update catalog nimble --json '{
  "changes": [{
    "principal": "account users",
    "add": ["USE_CATALOG", "USE_SCHEMA", "SELECT"]
  }]
}'
Replace account users with whichever UC group / service principal should have read access.
5

Query the table

The fully-qualified path is <catalog>.<shared_as>. For Shared as = data.products and a catalog mounted as nimble:
SELECT * FROM nimble.data.products LIMIT 100;

​
Subsequent runs

Once mounted, every subsequent Job run refreshes the shared table - the catalog mount itself is permanent. Each successful run also resets the 14-day retention clock on the shared table; if a Job stops running (or runs less frequently than every two weeks), the table will eventually age out of the share. Re-run the CREATE CATALOG step only if you delete the catalog, rename Shared as on the Job, or Nimble changes the share name (which won’t happen except on your explicit request).
Changing Shared as after the first run changes the path consumers query against (e.g., from nimble.data.products to nimble.curated.products). Plan downstream queries and views accordingly - and prefer keeping Shared as stable.

​
Persisting the data

The shared table is only guaranteed to be queryable for 14 days after each Job run. To hold the data longer - or to keep a frozen per-run snapshot for audit / historical analysis - materialize it into a UC table you own. Two common patterns: 
CREATE OR REPLACE TABLE my_catalog.my_schema.products
AS SELECT * FROM nimble.data.products;
Wire this as a Databricks Job, a Lakeflow Declarative Pipeline, or any other UC-aware orchestrator, scheduled to run shortly after Nimble’s Job cadence. Once materialized, the data is fully under your control and survives Nimble’s retention window.
Schedule the materialization a few minutes after Nimble’s Job is expected to finish, not at the same time. If you run too early you’ll snapshot the previous run; if you run too late you stay within the 14-day window with plenty of buffer either way.

​
Reference summary

WhatValue
Nimble’s global metastore ID (used when you create a recipient pointing to Nimble)aws:us-east-1:2f3ba1b1-429c-491f-b37d-ebb46f22f3e9
Input direction - your roleProvider (you run databricks recipients create + shares create + shares update + grants update share)
Destination direction - your roleRecipient (you run databricks providers list + catalogs create + grants update catalog)
Where to find your global metastore IDSELECT current_metastore() or databricks metastores summary
Destination data retention14 days from each successful Job run. Materialize into a UC table you own to retain longer.

All connections

Browse every Job storage connector.

Amazon S3

Connect a Job via an S3 bucket policy instead.