Help Center

Databricks Delta Sharing

Availability: Delta Sharing for the catalog is an early-access capability and depends on your plan. It requires a Databricks (or Delta Sharing–compatible) lakehouse on your side. Contact your Altana account team to set it up.

If you run a Databricks lakehouse, you can connect it to your Altana catalog with Delta Sharing — the open protocol for sharing live tables between platforms without exporting or copying files. One shared connection replaces a file feed: the data stays where it lives, and both sides read the current version.

Altana uses Delta Sharing in both directions, and you can use either or both:

  • Into Altana — you share a table of products and suppliers from your lakehouse, and Altana reads it on a schedule to build and maintain your catalog.
  • Out of Altana — Altana shares your maintained catalog back to your lakehouse, so your own tables stay in sync with what's in Altana.
Your Databricks lakehouse Altana catalog Refresh — Altana reads your table Sync — you read Altana's share

Refresh and sync run over the same Delta Sharing connection — each direction has its own provider and recipient.

How Delta Sharing works

In Delta Sharing, one side is the provider that shares a table and the other is the recipient that reads it. The recipient always sees the provider's current data — there's no export step, no file to schedule, and no copy to keep in sync by hand. Access is read-only and scoped to exactly the tables the provider chooses to share.

Which side is which depends on the direction: to refresh your catalog, you're the provider and Altana is the recipient; to sync the catalog back out, Altana is the provider and you're the recipient.

Refresh your catalog from Databricks

Instead of exporting a file, you share a table directly with Altana:

  1. In your lakehouse, build a table that lists your products and your suppliers. Your Altana team then works with you to match that table's columns to the fields Altana expects — the Supply Chain Data Template (SCDT), which describes products, suppliers, supplier locations, and how they connect. See Getting Data In for what each field unlocks.
  2. Share that table with Altana as a Delta Sharing recipient. You control the access — it's read-only, and limited to the table you share.
  3. Altana reads the shared table on a recurring schedule you agree on — for example weekly or monthly — and loads it into your catalog.

Each read reconciles the shared table against your catalog: records you've shared before are matched and updated in place, and new rows create new records. Because a read reconciles the catalog to the table, your shared table is the source of truth — a record you remove from the table is removed from the catalog on the next read. You maintain your catalog simply by keeping your own table current; the refresh needs no export and no upload.

Share your complete product and supplier set. A read mirrors the catalog to the shared table, so rows missing from the table are removed from the catalog. Share the full set you want reflected, not just recent changes.

For how to structure the data — the fields that identify a record and how multi-tier supply chains map into the catalog — see How Catalog Uploads Work.

Sync your catalog to your lakehouse

Altana can also share your catalog out over Delta Sharing, so the products, suppliers, and relationships Altana maintains are available as live tables in your own environment:

  1. Altana creates a share for your catalog and grants your lakehouse access to it as a recipient.
  2. You add the share in Databricks and query it like any other table — in notebooks, dashboards, or downstream jobs.
  3. As your catalog changes in Altana, the shared tables reflect the current state, so your lakehouse stays in sync without a pipeline to maintain.

This is the lakehouse-native counterpart to Catalog Subscriptions: subscriptions push individual product changes to an endpoint as events, while a Delta share exposes the whole catalog as queryable tables for you to read on your terms.

Choosing Delta Sharing or file ingestion

Both keep your catalog current; the right one depends on where your data lives.

  • Delta Sharing fits when you already run a Databricks or Delta Sharing–compatible lakehouse. There are no files to produce or move, and the connection is live in both directions.
  • SFTP and S3 file ingestion fits when your source system exports files. You drop SCDT files on a schedule and Altana loads them.

You can use both — for example, refresh the catalog from a shared table while a downstream team reads the catalog back out over its own share.

Getting set up

Delta Sharing is configured with your Altana team. Depending on the direction, you'll agree on the table to share and its mapping to catalog concepts, the recipient details for each side, the refresh schedule, and the region your data is served from. Your team validates the first read or share before it runs on a schedule.

Related