Data Cloud zero copy: the hidden trade-offs explained

Zero copy is one of those Data Cloud features that sounds almost too good to be true.

Use the data sitting in Snowflake, Databricks, BigQuery or Redshift inside Salesforce… without copying it in.

Cool, right?

Quick naming note before we start: Salesforce renamed Data Cloud to Data 360 at Dreamforce 2025. Same platform, new name — so you’ll see both in this post, and in the documentation.

But here’s the thing I think is worth paying attention to with Data Cloud zero copy: it isn’t one single feature.

There are actually four different ways it can work.

Some never store your data in Data 360. One of them does.

Some run on your warehouse’s compute. Some don’t.

And the cost — in Data 360 credits and on your warehouse bill — changes quite a bit depending on which one you pick.

So, let’s have a look.

Data Cloud zero copy in a nutshell

If you only have 30 seconds:

• Live query — Data 360 asks your warehouse; only the results come back.
• Caching (acceleration) — a scheduled copy of the federated data, kept in Data 360.
• File federation — Data 360 reads open-format files (Apache Iceberg) straight from your object storage.
• Zero copy data sharing — the reverse direction: Data 360 data made available inside Snowflake, Databricks and co.

The rest of this post is the detail behind those four lines.

First, what does Salesforce mean by zero copy?

Salesforce describes zero copy as a technology that “enables enterprises to access and query data without copying it”.

It works in two directions:

• Data in (zero copy data federation) — Data 360 uses data that lives in your lakehouse or warehouse, for things like segmentation and identity resolution, without ingesting it.
• Data out (zero copy data sharing) — Data 360 data, such as unified profiles and calculated insights, is made available to an external platform without building an export pipeline.

Out of the box, Salesforce lists Snowflake, Databricks, Amazon Redshift and Google BigQuery. The Zero Copy Partner Network launched in April 2024 with AWS, Databricks, Google Cloud and Snowflake, and Microsoft and IBM have joined since.

The “data in” side is where it gets interesting, because Data 360 has three different ways to read that external data.

Let’s get into it.

1. Live query (query federation)

This is the one most people picture when they hear “zero copy”.

When Data 360 needs the data, it sends a query to the external platform. According to Salesforce’s Data 360 Interoperability guide, the query is pushed down to the source, the warehouse does the work, and only the results come back.

Nothing is stored in Data 360.

• Where the work runs: your warehouse
• Freshness: as fresh as the source
• Cost: Data 360 credits for each query and compute on your warehouse

Example scenarios

• A segment filters on loyalty tiers stored in Snowflake — checked when the segment publishes, not loaded overnight.
• Order history in Redshift that’s only used now and then for an audience, so a full ingestion pipeline isn’t worth it.

And here’s the bit to watch.

Salesforce calls this a “pay-per-query model”, and warns that costs “may spike significantly at high QPS”. Performance also depends on the external system — overly broad queries and joins between Data 360 data and federated data are common causes of latency, according to this Salesforce blog.

So “zero copy” doesn’t mean “zero cost”. It means the cost moves to query time.

2. Caching (accelerated query)

Now things get a little more interesting.

Acceleration — you’ll also see it called caching or Accelerated Query — “temporarily stores cached copies of federated data in Data 360”.

Yes… the zero copy option that involves a copy.

The cache refreshes on a schedule you configure, anywhere from 15 minutes to 7 days. Queries then hit the cache instead of your warehouse, which makes them faster.

• Where the work runs: Data 360 (your warehouse only works during refreshes)
• Freshness: as of the last refresh
• Cost: Data 360 credits for the rows cached, plus external storage costs

One detail that’s easy to miss. Salesforce notes that “incremental refresh supports upserts only. Deleted records aren’t removed from the cache.” So a periodic full refresh is a good idea, otherwise deleted records can quietly hang around in your segments.

Salesforce also says caching is “not suitable for sub-second decisioning”.

Example scenarios

• A daily dashboard built on a million records and viewed 20 times a day — read a lot, changes a little.
• A product catalogue that changes weekly but is used in almost every segment.

3. File federation

The third option is the one the Salesforce blog calls “the third and best way” to connect to data lakes.

Instead of asking your warehouse’s engine to run a query, Data 360 reads the data files directly from object storage — Amazon S3, Google Cloud Storage or Azure Data Lake Storage — using open table formats like Apache Iceberg. It’s read-only.

Your warehouse’s compute isn’t involved at all.

• Where the work runs: Data 360, reading the files directly
• Freshness: whatever is in the files — Salesforce says it’s “not suitable for real-time dashboarding”
• Cost: no cost on the external lake, and very little in Data 360 if you stay in the same region

And region really matters here.

The blog says that if your data lake and Data 360 are in the same region, “the cost is almost zero on both sides”. The architects’ guide goes further: for same-region setups, “credits aren’t consumed for the rows that are accessed”, while cross-region or cross-cloud access does consume credits.

Performance depends on file format, partitioning and network I/O, so a well-organised lake matters.

A note on availability: Salesforce’s zero copy page still labels file federation as beta, while Databricks’ documentationlists it as generally available. Check the current status for your platform before you design around it.

Example scenarios

• Years of transaction history in Iceberg tables on S3 — far too big to ingest, but useful for segments.
• Propensity scores written to the lakehouse by the data science team, read by Data 360 in the same region.

4. Zero copy data sharing

And finally, the other direction.

Data sharing makes Data 360 data available in an external platform, without an export job. The setup, as described in Snowflake’s documentation, has two parts:

• A data share — which Data 360 objects you want to make available.
• A data share target — the receiving account, such as your Snowflake account.

Link the two, and the shared objects appear on the other side. In Snowflake, they show up as a data product you can mount.

One limitation worth knowing: you can’t share an external data lake object, or a data model object mapped to one. In other words, you can’t federate data in and then share it straight back out.

Example scenarios

• Unified profiles and a lifetime-value calculated insight shared to Snowflake for the finance team’s BI reports.
• The data science team trains a churn model in Databricks on shared Data 360 engagement data — and the scores come back in through federation.

Data Cloud zero copy options side by side

Here’s how the three “data in” options compare:

The credit figures are the ones quoted in Salesforce’s Four lessons from implementing zero copy blog. Treat them as indicative, and check the credit consumption help article and your own contract before you build a business case.

So what does it actually cost?

The biggest surprise for most teams is that Data Cloud zero copy can cost money in two places: Data 360 credits, and your warehouse bill.

Salesforce’s architects’ guide has two examples that show why the “right” option depends on how the data is used:

• Caching wins: a dashboard on 1M records, with ~10K changes a day, viewed 20 times a day – about 600 credits a month with acceleration vs ~4,200 with live queries.
• Live query wins: a segment published 20 times a day, on data that changes every 30 minutes – about 4,200 credits a month with live queries vs ~28,800 with acceleration.

Same platform. Very different answers.

The rule of thumb from the guide: if data is “accessed frequently but changes infrequently”, acceleration is typically more cost-effective.

So what should we actually take away from all this?

For me, the biggest takeaway is this:

“We’re using zero copy” isn’t really a useful statement.

Which zero copy? For which data? Read how often?

When you’re designing a Data Cloud zero copy setup, I’d ask five questions.

1. Which way is the data going?

Into Data 360? That’s federation. Out to Snowflake or Databricks? That’s sharing.

2. Is this core data, or everything else?

Salesforce’s guidance is to ingest critical data for canonical data models and core governance, and use zero copy for everything else.

3. How fresh does it need to be?

Minutes matter → live query. Yesterday’s data is fine → caching or file federation.

4. How often will it be read?

Read constantly but rarely changing → caching. Changing constantly → live query.

5. Where does it live, and who governs it?

Same-region object storage makes file federation very attractive. Avoid cross-region access unless you really need it.

And remember that with federation, a lot of the security lives in the source. Salesforce recommends row-level security and masking policies directly in the federated systems. As the blog puts it: “Permissions and governance are not details; they form the backbone of the entire model.”

The bigger picture

I think Data 360 zero copy is one of the most useful things about the platform.

And honestly, the fact that there are four options is a good thing.

But we need to be a bit more precise in how we talk about it.

Instead of asking:

Should we use zero copy?”

I’d ask:

Which way is the data going, how fresh does it need to be, how often will we read it, and where does it live?”

That’s a much more useful conversation.

Because, as we’ve seen, Data Cloud zero copy doesn’t mean zero movement — and it definitely doesn’t mean zero cost.

It means choosing where the work happens, and who pays for it.

So the next time someone says, “Let’s just use zero copy”, you know what to ask:

“Well… which zero copy are we talking about?”

If you’re curious how Data 360 data feeds the new AI features in Marketing Cloud, check out my recent post on smart features in the new Marketing Cloud Next.