Salesforce Data 360 vs. Databricks: the zero-copy bridge, the shared models, and the day the partner became a competitor

We made this argument once already about Snowflake, and the Databricks version of the meeting is nearly identical — until it isn’t. A company runs Databricks for its lakehouse: the pipelines, the feature tables, the models the data science team ships. Then the Salesforce account team pitches Data 360 — Data Cloud, renamed at Dreamforce 2025 and folded under the Agentforce 360 umbrella — as the data foundation for agents. Two consumption-priced platforms that both store data, both run SQL-shaped workloads, and both now claim to do AI. Procurement asks which one survives the budget.

It’s the wrong question, and the two vendors have spent two years proving it — building a bidirectional zero-copy bridge and standing on each other’s keynote stages. Then, on June 16, 2026, at its own Data + AI Summit, Databricks did two things in one morning: it expanded the Salesforce partnership into “the shared foundation for human and agent work” — and it launched CustomerLake, an agentic CDP with identity resolution and activation aimed squarely at Data 360’s turf. So the honest version of this post isn’t just “how to use both.” It’s how to build on a bridge whose far end now sells the thing you crossed it to get.

Two platforms, two centers of gravity

Strip away the overlap and the products are built for different jobs.

Databricks is a general-purpose Data Intelligence Platform — the branded name for the lakehouse. Its gravity is engineering and machine learning: Delta Lake and Apache Iceberg for storage, Unity Catalog for governance, Databricks SQL for the warehouse workload, Mosaic AI and MLflow for the model lifecycle, Lakeflow for ingestion. Nothing in it assumes your data is about customers. Feed it clickstreams, general-ledger entries, or sensor telemetry and it’s equally happy. It is a workbench for whatever data problem you have.

Data 360 assumes the opposite. Everything in it is organized around one entity — the customer — and one pipeline: ingest from CRM, commerce, and service; harmonize to the Customer 360 Data Model; run identity resolution to collapse duplicate records into unified profiles; compute segments and insights; and activate the result into journeys, ad platforms, Flows, record pages, and the retrieval indexes that ground Agentforce at runtime. It is not a workbench. It’s an assembly line for turning fragmented customer records into agent-ready context.

The distinction that matters most, and the one lakehouses keep tripping on: identity resolution is not native to Databricks. A lakehouse stores whatever you model; it has no built-in notion that these three rows are the same person. Data 360 does that as configuration — match and reconciliation rules producing unified profiles, with the platform’s own key-ring model linking source records rather than flattening them into one lossy golden record. That capability is the strongest reason Data 360 exists alongside a lakehouse — and, not coincidentally, exactly what CustomerLake now attacks.

The bidirectional bridge: what actually crosses it

The integration is the clearest evidence that “vs.” is the wrong frame. It runs both directions, and both are zero-ETL — no scheduled export, no second copy to reconcile. But the two directions use different machinery, and knowing which is which saves you a week of confusion.

Databricks reads Data 360. This uses Databricks’ own Lakehouse Federation, and there are two connectors, not one. A file sharing connector mounts Data 360 objects into Unity Catalog and queries them with Databricks compute; it authenticates with Workload Identity Federation — no secrets to manage — and wants a Unity-Catalog-enabled workspace on Databricks Runtime 16.3+, standard access mode (not single-user clusters), and a Pro or Serverless SQL warehouse. A separate query federation connector goes over JDBC with filter, aggregate, and join pushdown, authenticated by OAuth against a Salesforce connected app:

-- Databricks query-federation OAuth scopes for the Data 360 connection
cdp_api api cdp_query_api refresh_token offline_access

-- Callback URL registered on the Salesforce connected app
https://<your-databricks-instance>/login/oauth/salesforce.html

Data 360 reads Databricks. This is Data 360’s own zero-copy file federation, and it speaks Iceberg. The source data has to be Apache Parquet in Apache Iceberg table format, exposed through an Iceberg REST Catalog — and Databricks Delta tables qualify without conversion, because UniForm surfaces a Delta table as Iceberg on read. Data 360 then reads those tables directly at the storage layer with its own compute; there’s no Databricks cluster spun up and no external compute bill for the read. Mounted this way, a Databricks table behaves like any other data lake object in Data 360 — you map it into the Customer 360 model and it can feed identity resolution, segments, and grounding.

So the mental model is: Databricks pulls Data 360’s resolved customer into the lakehouse for analytics and ML; Data 360 pulls Databricks’ engineered and modeled tables in to enrich profiles and ground agents. The zero-copy mechanics — and the cases where “zero copy” quietly materializes a cached copy — are the same ones we’ve mapped before; they apply here with Iceberg as the interchange format.

The part Snowflake doesn’t have: shared models

If the federation story were the whole story, Databricks would just be Snowflake with a different table format. The real differentiator is the model layer.

Data 360’s bring-your-own-model path — Einstein Studio Model Builder — connects a predictive model hosted in Databricks and scores Data 360 data without moving features out. You train a churn or propensity model in Databricks on the full lakehouse feature set, register it, and its predictions flow back to enrich the unified profile — the same BYOM pattern we cover for predictive AI, pointed at Mosaic AI and the Databricks model registry. Snowflake’s relationship with Data 360 doesn’t emphasize this shared-model dimension; Databricks’ does, and it’s the reason a data-science-heavy org often prefers the Databricks side of the bridge.

One precision worth getting right, because it trips people in security reviews: this is predictive scoring, not generation. The Einstein Trust Layer is a generative-AI construct — masking, grounding, toxicity checks, and the audit trail wrap a prompt-and-response journey. A BYOM model that returns a churn probability produces a number, not generated text, so the Trust Layer’s masking and toxicity pipeline simply isn’t in that path. That’s not a gap to alarm anyone; it just means the governance of a predictive score — how it’s used, who sees it, what it’s allowed to trigger — is your architecture’s job, not something the Trust Layer confers for free. (Generative BYO-LLM calls are different: those do route through the LLM gateway and Trust Layer.)

Where each wins, and the use-both architecture

The comparison that actually helps a buyer is job-by-job.

	Databricks	Salesforce Data 360
Primary job	General-purpose lakehouse: engineering, transforms, ML/AI	Customer identity, activation, and agent grounding on the Salesforce platform
Data model	Whatever you design; domain-agnostic	Opinionated Customer 360 model (DLOs mapped to DMOs)
Identity resolution	Not native — build it	Native match/reconciliation producing unified profiles
ML / model training	Core strength: Mosaic AI, MLflow, Feature Store	Consumes models via BYOM; not a training platform
Segmentation & activation	Assemble it (now: CustomerLake)	Native to journeys, ads, Flow, CRM surfaces
Agent grounding	Not its job	Retrievers and indexes that ground Agentforce
Governance	Unity Catalog	Data 360 permissions & data spaces
Wrong use	Being your CRM’s consent-aware activation layer	Being your enterprise engineering and ML lake

The pattern we recommend when a client owns both starts from one principle: every dataset has a single home, and the other platform gets a pointer.

Databricks is the engineering and ML lake of record. All domains land there; pipelines, transforms, feature engineering, and model training happen there. If a table needs heavy computation, cross-domain joins, or years of retention, it lives in Databricks. Adopting Data 360 shouldn’t demote the lakehouse an inch.

Data 360 owns only what activation and agents need — the harmonized customer model, identity resolution output, consent, segments, insights, and the retrieval indexes that ground agents. Salesforce CRM data flows in through the internal connector; Databricks tables federate in as Iceberg; models score in place via BYOM. Everything arrives by decision, not by default.

Resolved identity flows back out. Unified profiles and segment membership share back into Unity Catalog through the file sharing connector, so the churn models and LTV analyses running in Databricks are built on the same resolved customer the agents use. That closes the loop: Databricks computes on the best available customer picture, and its outputs federate back in to drive activation and grounding.

The anti-patterns are that design run backwards — bulk-copying the lakehouse into Data 360 “so it’s all in one place” (you’ve built a worse, pricier lakehouse), rebuilding company-wide analytics on Data 360 queries, or running two disconnected customer models whose numbers never match. Deciding which datasets sit on which side of the line is most of the work, and it’s exactly what a data and AI strategy engagement exists to settle before contracts are signed.

The gotchas that decide whether this works

Zero copy is not zero work, and it’s not zero latency. Four things bite in production:

• Pushdown is close to all-or-nothing. A federated query is fast only when the whole query can be pushed to the remote engine. Mix a federated Databricks table with local Data 360 data in one operation and pushdown breaks down, dragging rows across the wire. Design queries to stay on one side.
• Federation is the wrong tool for conversational latency. If an agent needs a fact mid-conversation, a live federated query against Databricks will make the customer wait. The right move there is to ingest or accelerate into Data 360 — materialize the hot path locally and reserve federation for the reference data a segment touches occasionally. Acceleration (caching) lowers latency on large federated sets but reintroduces cost and staleness; it’s a deliberate trade, not a default.
• Changes on the far side don’t trigger anything. Because Salesforce initiates the federated calls outbound, a row changing in Databricks can’t immediately wake a Flow or an agent. If you need event-driven reactions, you need an event mechanism, not federation.
• Governance is still two systems. Unity Catalog governs the Databricks side; Data 360 governs its own. The June 2026 announcement put Federated Authentication, identity mapping, and governance interoperability on the roadmap for H2 2026 and beyond — which is the honest way of saying unified cross-platform governance isn’t shipped yet. Plan for two policy planes today.

And the cost note neither sales deck volunteers: federation can bill on both meters. A live segment refresh against a federated table consumes Data 360 credits for the rows accessed and Databricks compute for the pushdown that executes it. Usually still cheaper than maintaining pipelines and duplicate storage — but an unfiltered scan of a large federated table will prove otherwise on two invoices in the same month.

The elephant: your partner now sells a CDP

Here’s what makes the Databricks decision different from the Snowflake one. On the same day it deepened the Salesforce partnership, Databricks launched CustomerLake — an agentic CDP with identity resolution, audience building, and activation. Databricks’ CEO declines to frame it as competitive, but the overlap with Data 360 is explicit and unavoidable: the one capability that most justified running Data 360 next to a lakehouse — resolving identity — is now something the lakehouse vendor sells too.

Don’t over-rotate on it. A same-day product launch is not a shipped, proven, deeply-integrated CDP, and Data 360’s advantage is its native wiring into the Salesforce estate — journeys, Service Cloud, record pages, and Agentforce grounding that a lakehouse-native CDP has to integrate toward from the outside. But it does change how you should architect: keep the boundary between the two platforms explicit and reversible. Own your identity resolution rules, your segment definitions, and your activation logic as portable assets rather than deep, unspokable configuration in one vendor’s console. Design so that if the strategic ground shifts again — and on this evidence it will — you can move the activation layer without re-resolving every customer from scratch. That discipline is good architecture regardless of the rivalry; the rivalry just makes it urgent.

Stop comparing platforms; assign jobs

Two years of joint engineering — a bidirectional, zero-ETL bridge each company promotes on its own blog — tell you how the vendors see the technical relationship, even as their sales strategies converge. Databricks isn’t trying to be your CRM’s consent-aware activation layer. Data 360 isn’t trying to host your data science team’s training runs. They’re converging on features and diverging on jobs, and the June 2026 CustomerLake launch is the first real test of whether that stays true.

So reframe the evaluation the same way we always do: which datasets need company-wide engineering, ML, and governance — that’s lakehouse work. Which need identity resolution, activation, and agent grounding inside the Salesforce estate — that’s Data 360 work. What crosses the boundary, in which direction, and on whose meter? Answer it that way and the design for most Salesforce-plus-Databricks enterprises is boringly clear: keep Databricks as the engineering and ML lake, scope Data 360 to identity and the agent surface, join them with zero copy and shared models, police both meters — and keep the seam clean enough that you can renegotiate it when the partnership does.

Understanding the basics

Is Salesforce Data 360 a replacement for Databricks?

No. Databricks is a general-purpose lakehouse for data engineering, transformation, and machine learning across every business domain. Data 360 is a customer-identity, activation, and agent-grounding layer attached to the Salesforce platform — its defining capability, identity resolution, isn’t native to a lakehouse at all. Most enterprises that own both should connect them with zero-copy federation rather than choose: Databricks as the engineering and ML lake, Data 360 as the activation and grounding layer, with resolved identity shared back to the lakehouse.

How does zero-copy work between Data 360 and Databricks?

It’s bidirectional and uses different machinery each way. Databricks reads Data 360 through Lakehouse Federation — a file sharing connector that mounts Data 360 objects into Unity Catalog, or a JDBC query federation connector with pushdown. Data 360 reads Databricks through its own file federation against Apache Iceberg tables exposed via an Iceberg REST Catalog, with Databricks Delta tables surfaced as Iceberg by UniForm so no conversion is needed. Neither direction persists a copy by default; the exception is Data 360 Acceleration, which caches data locally to cut latency at the cost of some staleness and spend.

Can I use a Databricks model to score data in Salesforce?

Yes — that’s bring-your-own-model. You train a predictive model in Databricks on the full lakehouse feature set, register it, and connect it through Einstein Studio Model Builder so it scores Data 360 data in place, with predictions flowing back to enrich the unified profile. Because this is predictive scoring rather than text generation, the Einstein Trust Layer’s masking and toxicity pipeline doesn’t apply — that governance is your architecture’s responsibility. Generative BYO-LLM calls are the separate case that does route through the Trust Layer.

---

Trying to work out where your lakehouse should end and Data 360 should begin — and how to keep the seam clean while the vendors circle each other? Talk to us. Drawing that boundary is exactly the work we do.