Zero copy in Salesforce Data 360: a practical guide to what moves and what it costs

The demo is genuinely impressive. A Snowflake table appears inside Salesforce Data 360 in a few clicks — no ETL job, no pipeline to babysit, no second copy of your data drifting out of sync. Salesforce calls it zero copy, and the pitch is simple: access external data without moving, copying, or reformatting it, by creating a pointer that tells Data 360 where the source data lives.

The pitch is mostly true. It’s also incomplete. In practice, “zero copy” describes a family of techniques — live query federation, file federation, cached acceleration, outbound data sharing — with very different behavior. Some of them copy data. Several of them bill you per row scanned, not per row returned. And because federated queries run on your warehouse’s compute, you can end up paying twice for the same segment refresh: once in Data 360 credits and once on your Snowflake or Databricks bill. We’ve seen teams adopt zero copy to save money and end up spending more than plain ingestion would have cost.

This post walks through what zero copy actually is in Data 360, both directions of it, where data still materializes, how the cost model really works, and how to make the ingest-or-federate call per data source.

What zero copy actually means in Salesforce Data 360

First, naming. Salesforce renamed Data Cloud to Data 360 in October 2025 as part of the Agentforce 360 repositioning; the documentation still says “Data Cloud” in plenty of places, but it’s the same product and the same zero-copy machinery underneath.

Mechanically, zero copy is metadata. When you connect an external table, Data 360 stores metadata that tells Salesforce where the data lives, how to find it, and how to read it — nothing else. The table surfaces as an external data lake object (DLO), which acts as a reference pointing to data physically stored in your warehouse. You then map that DLO to a data model object (DMO) exactly as you would for ingested data, and downstream features — segmentation, identity resolution, calculated insights, Agentforce grounding — mostly don’t care that the rows live elsewhere.

Salesforce formalized this with the Zero Copy Partner Network in 2024, with AWS, Databricks, Google Cloud, IBM, Microsoft, and Snowflake as the founding platform partners. The commitment is bidirectional, which is the part most summaries skip. Zero copy has two distinct directions:

• Data federation (data in). External tables from Snowflake, Google BigQuery, Databricks, and Amazon Redshift become queryable inside Data 360 without ingestion.
• Data sharing (data out). Data 360 objects — including unified profiles and calculated insights — become queryable tables and views inside your warehouse, without an export pipeline.

The scale is real. Salesforce’s engineering team reported that, over one six-month span of 2024, Data Cloud queried 4 trillion records in external systems, while external systems accessed 250 billion records from Data Cloud. This isn’t a fringe feature. Which is exactly why the cost mechanics deserve scrutiny.

Data federation in: three connection methods, three cost profiles

“Federate this table” is not one decision. Data 360 offers three distinct methods for reaching external data, and choosing between them is where most of the architecture — and most of the money — lives.

Method 1: Live query federation

The default zero-copy mode. Data 360 sends the query to the external system’s query engine, which executes it and returns only the result set. The connection runs over a JDBC driver, and Data 360 pushes filters down to the source so the warehouse does the heavy lifting. Data is always current, because there is no copy to go stale. The trade-off: every segment preview, every activation, every identity resolution run that touches the object fires a real query against your warehouse — which needs a running warehouse, with warehouse pricing, every time.

Method 2: Cached acceleration

Acceleration is the setting demos gloss over. Flip it on and Data 360 caches the external data as a data lake object and refreshes it on a schedule, with incremental refreshes as frequent as every 15 minutes. Call it what it is: batch ingestion wearing a zero-copy badge. The billing agrees — accelerated streams are metered as an external batch data pipeline, on rows processed. You’d enable it for performance, for cross-region sources, or because a feature demands it (more on that below). But you’ve reintroduced a copy, a refresh schedule, and staleness. The three things zero copy was supposed to eliminate.

Method 3: File federation

The newest and, for large tables, often the best option. Instead of asking the warehouse’s engine to run queries, Data 360 reads Apache Iceberg tables directly at the storage layer using its own compute — no warehouse cluster involved, no external compute bill. Salesforce launched file federation in beta in June 2025 for AWS Lake Formation, Databricks, Snowflake, and any lake with an Iceberg REST catalog; Databricks Delta tables work via UniForm without conversion. It also enables change-data-capture-based features without caching, which live query can’t do. The catch is table-format and catalog readiness: if your lake isn’t on Iceberg (or Delta with UniForm enabled), this path isn’t available to you yet.

One practical note from Salesforce’s own guidance: whichever method you choose, filter at the source, start with a modest dataset — around 50 million rows — and use a WHERE clause when setting up query federation. Federating a 10-billion-row raw events table because you can is how the horror-story invoices happen.

Data sharing out: your unified profiles as warehouse tables

The reverse direction gets less attention but is often the easier win. Data sharing lets you expose Data 360 objects — data lake objects, data model objects, and calculated insight objects — to your warehouse through a data share linked to a data share target, with no export job.

In Snowflake, the share appears under Private Sharing and is queried like any native database, authenticated via OAuth; under the hood it uses Snowflake’s data sharing plumbing, and the bidirectional integration has been generally available since April 2024. Equivalent share targets exist for Google BigQuery, Amazon Redshift, and Databricks. Databricks can also treat Data 360 as a source in its own right: Lakehouse Federation runs federated queries against Data 360 over JDBC with filter and aggregate pushdown, and a separate file sharing connector reads Data 360’s Iceberg tables directly.

Why this matters: the single most valuable thing Data 360 produces is the unified profile — the output of identity resolution across your CRM, service, and commerce data. Data sharing puts that table next to your finance and product data in the warehouse, where your analytics team already works, without anyone maintaining a reverse-ETL pipeline. For orgs whose data science lives in Databricks or Snowflake, we’d argue data-out sharing is the strongest single argument for the whole zero-copy program — and it’s frequently the piece an integration architecture review finds sitting unused in an org that already pays for it.

Note that sharing isn’t free either. Outbound data shares meter on their own line, separate from inbound federation: the published rate card charges data shared out at a higher per-million-rows rate than the rows-accessed rate a live federated query draws on, and Salesforce documents both under its billable usage types. A BI dashboard hammering a shared view keeps consuming credits for as long as it runs, so budget for the standing access pattern, not just the one-time share.

Where zero copy still copies: caches, indexes, and derived data

Time for the honest part. “Zero copy” means zero copies of the source table. It does not mean Data 360 holds no data. Four things still materialize:

• Acceleration caches. As above — an accelerated data stream physically ingests rows into a data lake object on a refresh schedule. That’s a copy, deliberately made, and billed like one.
• Search and vector indexes. If federated content feeds Agentforce retrieval or semantic search, Data 360 chunks the data and generates vector embeddings, storing chunks in chunk DMOs and embeddings in index DMOs — all inside Data 360. The source file stays put; a derived, searchable representation of it now lives in Salesforce. For unstructured data, that derived copy can be a meaningful fraction of the original.
• Unification outputs. Identity resolution, calculated insights, and batch transforms materialize their results locally in Data 360. Your unified profiles are new, physical data — that’s the point of building them.
• Anything needing triggers. Live query is pull-based, so a change in the external lake won’t fire a data action; trigger-based features require caching, or file federation’s CDC support where available. If your use case is “do something the moment a row changes,” pure federation can’t see the change until something queries.

None of this is a scandal — every federated system on the market works this way, and indexes over remote data have to live somewhere. But it changes the compliance story. If your legal team signed off on zero copy because “customer data never leaves the warehouse,” embeddings of that data sitting in index DMOs deserve a specific conversation, not a footnote.

The credit math: when federated queries cost more than ingesting

Zero copy’s cost model has one detail that dominates everything else: with acceleration off, charges apply to rows accessed, and “accessed” includes any rows scanned or touched by the query on the external system — not rows returned. A segment that filters 100 million rows down to 40,000 members pays for 100 million, on every preview, refresh, and activation.

The published rates make the trade-off calculable. Live query federation costs 70 credits per million rows retrieved, versus 2,000 credits per million rows for cached acceleration — the same order as batch ingestion. File federation consumes the same credits as live query but generates no cost on the external lake. So per touch, federation looks roughly 28 times cheaper than ingesting. The catch is the multiplier: ingestion pays per row once (plus incremental changes), while live query pays per row per query.

Run the arithmetic on a 100-million-row federated table with the published rates. One full-scan query costs about 7,000 credits. A daily segment refresh is roughly 210,000 credits a month — already more than the ~200,000 credits a one-time ingest of the same table would cost — and that’s before the second bill: every one of those live queries also ran on your warehouse’s compute, metered at Snowflake or Databricks rates. Ten segments on that table, refreshing daily, and federation is no longer the frugal option. This dual-cost effect is why Salesforce’s own implementation guidance insists on a TCO model covering both sides, and why Salesforce Ben’s analysis warns that query costs may simply shift between platforms without achieving real savings.

Latency compounds the cost story. Physics applies: keeping Data 360 and the lake in the same region materially reduces query time, and cross-region setups add delay, bandwidth constraints, and potential egress charges. Worse, joins between local and remote data can break query pushdown entirely — even an implicit join, like consent enforcement against a local consent DMO, can force Data 360 to pull far more remote data than the query appears to need. The practical mitigations are unglamorous: filtered views instead of raw tables, source-side sorting and partitioning, acceleration for the handful of hot datasets, and file federation in-region where your lake supports it.

Ingest or federate: a decision table for each data source

The right answer is per source, not per org. Salesforce Ben’s framework poses three qualifying questions before federating anything: is the lake actively managed (schema monitoring, ingestion schedules, failure alerts)? Does its refresh cadence match the business need? Is the dataset complete enough to serve the use case? A “no” on any of them points back to ingesting from the system of record — federating a neglected table just imports someone else’s data quality problem, live.

Past those gates, this is the decision table we work through with clients:

Source characteristics	Better fit	Why
Large, governed lakehouse table; queried occasionally or ad hoc	Live query federation	Pay 70 credits/M only when touched; always current; no pipeline
Very large Iceberg/Delta tables, heavy read volume, same region	File federation	No external compute bill; near-native scan performance
Mid-size table hit constantly by segments and activations	Acceleration (or ingest)	Repeated scans of the same rows quickly out-cost a cached copy
Fast-moving events that must trigger data actions	Ingest, or accelerate at 15-min refresh	Live query can’t fire triggers on external changes
Source in a different region or behind slow networking	Acceleration	Salesforce’s own guidance for cross-region latency
Poorly governed source, schema drift, partial history	Ingest from system of record	Federation inherits the source’s problems in real time
Warehouse-side analytics needing unified profiles	Data sharing (out)	Zero pipelines; analysts query Data 360 views natively

Two habits make this table work in practice. First, estimate query loads before connecting — simulate expected segment and activation volumes so the credit math is a forecast, not a post-mortem. Second, revisit the choices quarterly. Usage patterns drift; a table that was ad hoc in Q1 becomes the backbone of six segments by Q3, and the right method changes with it. This is exactly the kind of source-by-source mapping we run in a data and AI strategy engagement, because the ingest-or-federate call is ultimately a cost-and-latency model of your own workloads, not a feature checkbox.

Zero copy is an architecture decision, not a default

The marketing framing invites a binary: pipelines are legacy, federation is the future, copy nothing. The systems we see working don’t look like that. They look like portfolios — a few big Iceberg tables on file federation, a handful of hot datasets accelerated on 15-minute increments, the genuinely cold stuff on live query, core operational data still ingested from systems of record, and unified profiles shared back out to the warehouse where the analysts live.

That’s not a compromise of the zero-copy vision; it’s the vision applied honestly. Zero copy’s real contribution isn’t eliminating copies — caches, embeddings, and unified profiles mean copies of something will always exist. Its contribution is making data placement a reversible, per-table decision instead of a one-way pipeline commitment. Flip a table from live query to acceleration when usage grows. Drop the cache when it doesn’t. Share the profile table instead of building reverse ETL. Each choice is cheap to change, which is precisely what pipeline-era architectures never were.

So treat the technology with the respect reversibility deserves: measure both bills, know which of your “zero copy” objects secretly hold data, and re-run the decision table as workloads evolve. Do that, and zero copy stops being a slogan you bought and becomes what it should have been all along — one more placement option you control, per source, with your eyes open.

Understanding the basics

What is zero copy in Salesforce Data 360?

Zero copy is Data 360’s ability to work with external data without ingesting it. Data federation makes warehouse tables from Snowflake, BigQuery, Databricks, or Redshift queryable inside Salesforce via metadata pointers, while data sharing exposes Data 360 objects as live views inside those warehouses. Queries run against the source, so there’s no duplicate dataset to sync or reconcile.

Does zero copy really mean no data is copied?

No — it means no copy of the source table is required. Data still materializes in specific cases: cached acceleration physically ingests rows on a refresh schedule, search and vector indexes store chunks and embeddings inside Data 360, and identity resolution outputs like unified profiles are new local data. Pure live query and file federation, however, leave source rows in place.

When is ingestion cheaper than zero copy federation?

When the same large table is queried repeatedly. Live query federation bills around 70 credits per million rows accessed — including rows merely scanned — on every segment refresh, preview, and activation, plus external warehouse compute per query. Ingestion costs roughly 2,000 credits per million rows once, then increments. Frequent broad queries against big tables typically cross that break-even point within weeks.

---

Weighing zero copy against ingestion for your own warehouse and Data 360 setup? Talk to us — mapping these trade-offs is what we do.