Salesforce and Databricks Zero Copy: An Architect's Decision Guide
The pitch is simple: your CRM and your lakehouse read the same data without copying it. No pipelines to babysit, no nightly sync that broke at 2 a.m., no third copy of the customer table drifting out of date. Salesforce calls this zero copy, and for teams running both Data Cloud and Databricks it is one of the most tempting patterns in the current stack.
The pattern is real, and it earns the attention. But zero copy is an architecture decision with real trade-offs, not a checkbox in setup. Here is a decision guide worth walking through before anyone wires anything.
What Zero Copy Actually Is
At its core, zero copy means Data Cloud works against data that stays in an external lake such as Databricks or Snowflake instead of ingesting a copy, as Salesforce Ben’s analysis of the pattern lays out. The appeal for organizations that already run a governed enterprise lake is direct: the pipelines, quality controls, and governance you built once keep doing their jobs, and Salesforce reads the results in place.
The strategic effect is one governed copy of the truth, with each platform doing what it is good at: the lakehouse for scale computation and model training, Salesforce for customer context and action.
The Economics That Decide It
The cost asymmetry drives the architecture. The same analysis puts data federation queries at roughly 70 Data Cloud credits per million records, against about 2,000 credits per million for batch ingestion, nearly a thirty-fold difference in Salesforce-side cost for data you leave in place.
The catch is the second meter. As the analysis notes, federated workloads produce two sets of bills, one from Salesforce Data Cloud and one from your lake provider, and query volume on one side can drive compute cost on the other. A segment that a marketer refreshes hourly can quietly become a real Databricks line item. Model the total cost across both meters for your actual read patterns before committing, not after the first surprising bill.
Three Red Flags Worth Respecting
The same guide names three conditions under which zero copy is the wrong answer. A lake without monitoring and schema-change detection turns every upstream tweak into a silent CRM incident. A lake whose refresh cadence lags what the business needs pushes you back toward direct ingestion. And an incomplete dataset federated into Data Cloud just relocates the gap. Zero copy amplifies the quality of the lake you already have, for better or worse.
The Unglamorous Part: Permissions
In practice, early zero copy work is mostly governance work. A Databricks community thread on connecting Salesforce shows the shape of it: a practitioner’s connector appeared to work but showed no tables, and the fix was not sharing technology at all, just granting the service principal USE CATALOG on the catalog, USE SCHEMA on the schema, and SELECT on each table through Unity Catalog. That is good news: Unity Catalog grants are auditable and reviewable, exactly what your compliance team wants the answer to be.
One Caveat On Identity
The Salesforce Ben piece also flags an identity resolution gap: Data Cloud builds multiple contextual profiles through what it calls a key ring approach, rather than forcing one rigid golden record, and data sitting in an external lake does not get that treatment automatically. If your use case depends on stitching identities across sources, plan where that resolution happens before deciding which tables federate and which ingest.
What We Would Do
Our approach to this pattern follows a deliberate sequence. First, a lake readiness check: monitoring, schema-change detection, and refresh cadence, because the red flags above are cheap to find early and expensive to find in production. Second, a two-meter cost model built from your real query patterns, not the demo’s. Third, governance design in Unity Catalog before any connector is configured, so access is provable from day one. Then one scoped use case, a segment, a scoring feed, or an agent grounding source, shipped and measured before the pattern spreads.
That order sounds conservative. The point of it is that every later use case inherits answered questions: the lake is known-good, both finance teams trust the meter, and access is already provable.
Zero copy rewards teams that treat it as architecture and punishes teams that treat it as a feature flag. Decide like an architect, and the payoff, one governed copy of the truth serving both platforms, is durable.