Connecting Data 360 to Databricks with zero copy: federation in, sharing out

Your customer records live in Salesforce and your behavioural, product, and model-scoring data lives in a Databricks lakehouse. The old answer was a pipeline: schedule a job, copy the lakehouse tables into Data 360, then reconcile the two copies forever. The zero-copy connectors let you skip that, and unlike the Snowflake and BigQuery bridges, the Databricks one is two-directional and generally available in both directions.

One decision matters before any of the setup. Zero copy removes the pipeline and the second copy of the data. It does not remove the query cost, and it does not remove the modelling work.

Go in expecting “free” and you will be surprised by your credit bill and by how much shaping the federated tables still need. Go in expecting “no ETL, same query economics,” and it delivers.

The bridge runs both ways, and the directions are different jobs

“Zero copy with Databricks” is really two separate capabilities pointing in opposite directions. Salesforce lists the Databricks connector as GA for batch ingestion, Query Federation, File Federation, and Data Share. The two you care about for zero copy are federation in and sharing out.

Federation in brings Databricks tables into Data 360 without copying them. The tables show up as external data lake objects you can map into your data model, unify onto profiles, and ground an agent on, while the bytes stay in your lakehouse.

Sharing out exposes your Data 360 unified data to Databricks. Salesforce Data 360 File Sharing into Databricks Unity Catalog reached general availability in October 2025. A data scientist can then query the unified profile from a Databricks notebook without asking anyone to export a CSV.

Most teams need one direction first. Grounding a CRM agent on lakehouse data is federation in. Training a model or running BI on unified profiles is sharing out. Decide which problem you are solving before you touch Setup, because the prerequisites differ.

Federation in: File Federation or Query Federation

Data 360 can federate Databricks two ways, and the choice sets both your freshness and your cost.

Query Federation pushes a live SQL query down to your Databricks compute when Data 360 needs the data. You get whatever is current in the lakehouse, at the price of spinning Databricks compute on every read. It suits cases where freshness is non-negotiable and query volume is modest.

File Federation reads the underlying table files directly from object storage, so it never touches Databricks compute at all. Salesforce built it on Apache Iceberg: it reads the Iceberg metadata and the Parquet files where they sit.

That makes File Federation the cheaper, faster option at volume, which is why I default to it for anything reading large tables. The trade is that it depends on Iceberg metadata existing, and that drives every prerequisite below. File Federation reuses the same open-table pattern behind Data 360’s Iceberg file federation, pointed at a Databricks lakehouse.

If the distinction between what you map and what you model is new, start with the data lake object versus data model object mapping. That mapping step decides everything downstream, and it applies to a federated Databricks table exactly as it does to an ingested one.

What File Federation needs before it will connect

File Federation has hard prerequisites. Skipping the metadata one is the most common reason a connection that looks right returns nothing:

Unity Catalog, not Hive Metastore. The Databricks workspace has to be governed by Unity Catalog. Data 360 does not federate a Hive Metastore workspace.
Iceberg metadata on every Delta table. Unity Catalog must be configured to generate Iceberg metadata for the tables you want to read. A Delta table with no Iceberg metadata is invisible to File Federation.
The right storage. On AWS the data sits in an S3 bucket; on Azure it sits in ADLS Gen2, and Data 360 reads the files from there.
Runtime and access mode. Databricks clusters need Databricks Runtime 16.3 or above and standard access mode.

Once those hold, the Data 360 side is short. In Data Cloud Setup, under External Integrations, open Other Connectors, choose Databricks File Federation on the Source tab, name the connection, and supply the authentication.

A catalog access token (a Databricks personal access token) is the quickest way in. Use the OAuth option instead for anything production, so a rotating credential is not sitting in one person’s PAT. From there you create a data stream on the federated tables and map them like any other source.

The reverse direction is configured mostly from the Databricks side, and it leans on Delta Sharing under the hood. You create a connection to your Data 360 database and a foreign catalog in Unity Catalog that mirrors it.

After that, your Data 360 objects appear as catalog tables a notebook or a SQL query can read in place, with no copy landing in the lakehouse. Databricks documents the same runtime floor here, and SQL warehouses need to be on the Pro or Serverless tier for the connection to work.

This direction turns Data 360’s unified profile into a feature source for the data science team. The identity resolution, consent state, and calculated insights you built in Data 360 become columns a model can train on. No nightly export, and no model drifting from the CRM’s version of the customer.

Zero copy is not zero cost, and this is where it bites

The pitch is “no data movement.” True, and worth having. But three costs survive, and they are the ones that surprise people.

Query credits. Reading federated data consumes Data 360 credits the same way querying ingested data does. Zero copy saves you the storage of a second copy and the pipeline that maintains it. It does not make the reads free. A federated table an agent hammers on every conversation can cost more than a copy you ingested once and query cheaply. Model the read pattern rather than the storage alone, and lean on the credit optimization playbook before you point a high-traffic agent at a federated source.

Databricks compute, if you chose Query Federation. Every federated query runs on your Databricks warehouse and shows up on that bill. File Federation exists for exactly this reason, and it is the reason I reach for it whenever freshness allows.

Latency. A federated read crosses a network boundary and, for Query Federation, waits on Databricks compute to wake and run. For an agent that has to answer in a couple of seconds, that can be the difference between a snappy reply and a timeout. If a data graph or retriever is grounding a live agent, test the tail latency of the federated path under load, rather than only the happy path in a demo.

The honest framing is the one from the broader zero-copy guide: zero copy trades storage and pipeline cost for query-time cost and a dependency on the other platform’s availability. For slow-changing, high-volume reference data it is close to free. For hot, latency-sensitive data an agent reads constantly, an ingested copy is sometimes cheaper and faster. Choose per table, not per platform.

When to bridge, and when to just ingest

Federate when the data is large, changes on the lakehouse’s schedule, and you would rather not own a pipeline: product events, model scores, engineering-owned datasets that already have a home in Databricks. Share out when the data science team needs the governed customer view and you want one definition of the customer across CRM and lakehouse.

Ingest instead when a table is small, static, or read on every single agent turn, where a cheap local copy beats a metered federated read every time. And there is a third option entirely for reaching a handful of external rows from a screen. Salesforce Connect versus Data 360 zero copy is a real fork, and Data 360 is the wrong tool for “show me these five external records on a Lightning page.”

One strategic note is worth keeping in view. Salesforce and Databricks are partners on this bridge and competitors on the platform, a tension I unpacked in the Data 360 versus Databricks comparison. The zero-copy connector is a good enough reason to run both without picking a loser, which is what makes it worth building on.

If you are wiring a lakehouse to Data 360 to ground an agent and want the federation-versus-ingest call made table by table, with the credit math attached, that is squarely the integration and Data Cloud work we do.

Understanding the basics

What is zero copy between Data 360 and Databricks?

Zero copy is the ability to query data across Salesforce Data 360 and a Databricks lakehouse without physically copying it. You can federate Databricks tables into Data 360 as external data lake objects, and you can share Data 360 unified data into Databricks Unity Catalog, in both cases reading the data where it already lives.

What is the difference between File Federation and Query Federation?

Query Federation pushes a live SQL query to your Databricks compute, so results are current but every read spins Databricks compute. File Federation reads the underlying Iceberg files directly from object storage, so it never uses Databricks compute and is cheaper at volume, at the cost of depending on Iceberg metadata being generated for every Delta table.

What are the prerequisites for Databricks File Federation?

The Databricks workspace must be governed by Unity Catalog rather than a Hive Metastore, Unity Catalog must generate Iceberg metadata for the Delta tables, the data must sit in S3 on AWS or ADLS Gen2 on Azure, and clusters must run Databricks Runtime 16.3 or above in standard access mode.

Does zero copy avoid Data 360 credit consumption?

No. Querying federated data consumes Data 360 credits just as querying ingested data does. Zero copy removes the storage of a second copy and the pipeline that maintains it, not the cost of reading the data, so a high-traffic federated source can cost more than an ingested one you query cheaply.

The zero-copy bridge is the easy part; deciding which tables to federate, which to ingest, and what it costs an agent to read them is the work. If you want that mapped for your lakehouse before you build, talk to us.