Every Data Cloud conversation I’ve had in the last year eventually turns to Zero Copy. Someone read a blog post, saw a demo, and now wants to know why the team is still running nightly batch jobs to move data into Salesforce when Salesforce says you don’t have to copy anything at all. It’s a fair question. The answer is less exciting than the marketing: Zero Copy is the right tool for a narrow set of problems, and a genuinely bad fit for most of the integration work a typical org still needs.
I’ll say the quiet part up front. Zero Copy doesn’t mean “no copying happens anywhere.” It means Data Cloud can query data sitting in an external system, typically a data warehouse like Snowflake, Databricks, Redshift or BigQuery, without physically ingesting it into Data Cloud’s own storage first. Federated access, not teleportation. The data still lives where it lived. Salesforce reaches out and reads it on demand, or through a virtualised connection, instead of pulling a copy in and storing it locally.
What Zero Copy is actually solving
Three real problems, and they’re the ones worth checking your org against before you touch a connector.
Storage and duplication cost
Every record you ingest into Data Cloud takes up space and needs to be kept in sync. If your warehouse already holds ten years of transaction history and you only need the last 90 days visible inside a Salesforce flow, ingesting the full history is wasteful twice over: you’re paying for storage you don’t need, and you’re building a pipeline to keep a copy fresh that nobody asked for.
Freshness
Batch sync jobs run on a schedule. Hourly, nightly, whatever the pipeline was built for. If a contact-centre agent needs to see a customer’s current loyalty tier and that tier updates in near real time in the warehouse, a four-hour-old copy in Data Cloud is wrong exactly when it matters. Zero Copy queries the source directly, so the answer reflects what the warehouse has right now, not what it had at the last sync.
Governance and single source of truth
Some organisations have a hard rule, often from a previous audit finding, that customer financial or health data cannot be duplicated outside its system of record. Compliance teams like fewer copies, not more. Zero Copy lets Salesforce reference that data for a specific use case without creating another place it has to be secured, retained and eventually deleted.
Where a sync job still wins
This is the part that gets skipped in the demos. A traditional ingestion or sync pattern beats Zero Copy in a lot of ordinary situations, and pretending otherwise causes real problems six months later.
Query volume and latency
Federated queries go over the network to the source system, every time. If you’re building something that needs to evaluate thousands of records per second, inside a real-time decisioning flow or an Agentforce topic that fires on every page load, round-tripping to an external warehouse for each lookup adds latency you can’t always absorb. Ingested data sitting in Data Cloud’s own storage is fast because it’s local. That’s not a small detail. I’ve seen a well-intentioned Zero Copy design get quietly reverted after performance testing showed response times that were fine in a demo with ten records and unacceptable with ten thousand.
Transformation needs
If the data needs real shaping before it’s useful, identity resolution, calculated fields, harmonisation across multiple source systems, a batch pipeline that transforms on the way in is usually simpler to build, test and debug than trying to push that logic into a live federated query. Zero Copy is a read path. It’s not where you want to be doing heavy lifting.
Source system availability
A sync job decouples Salesforce from the warehouse’s uptime. If the warehouse has maintenance windows, rate limits, or occasional outages, a Zero Copy dependency means your Salesforce experience goes down with it. A local copy keeps functioning even when the source is briefly unreachable. For anything customer-facing, that resilience is worth more than the storage you save.
Cost at scale, the other direction
Zero Copy isn’t free. Federated queries against a warehouse usually cost compute on the warehouse side, and that cost scales with how often Salesforce asks. A high-frequency use case can end up more expensive querying live than it would have been ingesting a well-scoped subset once a day. Nobody puts that in the slide deck.
A decision framework that actually holds up
Before picking a pattern, I ask four questions, roughly in this order.
- How often does this data actually change, and does the use case genuinely need to see it the moment it changes, or is “accurate as of last night” good enough?
- What’s the query pattern: occasional lookups during a case or interaction, or high-frequency reads across a large population?
- Does the data need transformation, joining or harmonisation before it’s usable, or is it already clean and query-ready at the source?
- Is there a governance constraint that actively prohibits a second copy, versus a preference for “less duplication is nicer”?
If the honest answers are: rarely changes, low query volume, minimal transformation, and no hard governance block, Zero Copy might genuinely save you a pipeline. If any one of those tips the other way, especially the query volume question, a conventional sync is probably the safer build, and it’s the one your team already knows how to monitor and fix at 2am when something breaks.
What I tell clients
Zero Copy earns a place in an architecture when it removes a specific, named pain: a duplication rule from compliance, a freshness gap that’s actually been reported as a problem, or a dataset so large that ingesting it was never going to be practical. It’s not a default. I’ve started treating it the way I treat any other integration pattern choice: pick it because the requirements point there, not because it’s the pattern with the most momentum in the ecosystem this quarter. A sync job that’s boring, well-tested and runs every night without surprises is still, for most orgs, the right answer most of the time.
Leave a Reply