Zero Copy for Snowflake, Databricks, and BigQuery: A Practitioner's Read

A team asks to connect Salesforce to the warehouse you own. The pitch is reassuring: zero copy, your data never moves, no migration. The claim is true. It also hides three different architectures behind one phrase, and which one you get depends on the warehouse you already run.

This article is about zero copy architecture as a data pattern, not the operating-system trick with the same name. Here, zero copy means one thing: use the data where it already sits, without making a copy. Salesforce Data Cloud (now Data 360) says it works both ways: Data 360 can use your warehouse data without copying it in, and can share its own data back out (Salesforce Trailhead).

Most explanations stop at that definition. But under the label sit three different setups, with different costs, different limits, and different answers to who controls the data. This article walks through each one, and through what your specific platform supports.

Zero copy architecture is three mechanisms, not one

Start with the main term. Federation means the data stays in the system that owns it, and another platform queries it there. No export, no nightly sync, no second copy. The opposite is ingestion: copy the data in first, then use it.

*The trade in one picture: ingestion makes a second copy to get fast access; federation keeps one copy and pays per query.*

Zero copy works in both directions. To keep them straight, remember your seat in this story: you own the warehouse. When Data 360 reads your warehouse, that is federation. When your warehouse reads Data 360, that is sharing (Salesforce Trailhead).

Federation itself comes in two forms, query federation and file federation. The difference between them decides most of the cost and most of the risk.

*The general architecture: three paths through the same two stacks. Which paths your warehouse offers, and what each costs, is the rest of this article.*

1. Query federation: the other engine does the work

Data 360 sends a query to the external system's own engine, which runs it against storage and returns records. Salesforce's own docs teach it with a library: you hand your request to the clerk, and only the clerk enters the book room (Salesforce Trailhead).

Since the warehouse's engine does the work, you may pay compute fees on the warehouse side too. Every external system supports this mode. Databricks states it directly: the query "is run both in Databricks and using remote compute" (Databricks). Two engines run. Two meters tick.

*You ask the clerk; the clerk enters the book room. Both of you are on the clock.*

2. File federation: read the shelves yourself

Here Data 360 skips the clerk and walks into the book room. It reads the storage layer directly with its own compute engines, so there is no warehouse compute fee, per the same Salesforce module.

This mode works best for large datasets stored in open table formats like Apache Iceberg, and Salesforce recommends it wherever available. The catch: not every system supports it.

*You skip the clerk and read the shelves yourself. One meter runs.*

3. Data sharing: the same idea, reversed

Sharing runs the other way. Data 360 exposes its unified objects, and the external platform queries them in place, with no outbound pipeline to build or maintain, per Salesforce's data sharing module.

Three setups, one label. Here is the difference in one view:

Mechanism	Direction	Whose engine runs it	Who gets billed	Who enforces governance
Query federation	Data in	The warehouse's engine	Both: Salesforce credits plus warehouse compute	The warehouse (it executes the query)
File federation	Data in	Data 360's engine, reading storage directly	Salesforce credits; Snowflake may add a small catalog API fee	Shifts toward Data 360
Data sharing	Data out	The warehouse's engine, reading Data 360 objects	Data share credits (800 per 1M rows)	Data 360 exposes governed objects

The last two columns are the rest of this article. Who gets billed is the cost section. Who enforces governance is the section after it.

Salesforce engineering describes the change simply: query federation uses two compute engines, file federation uses one, reading shared storage in the Iceberg format (Salesforce Engineering). Keep that one-engine versus two-engines picture in mind. It drives the cost section below.

Why every vendor uses a different word for the same thing

Here is where it gets confusing. Each vendor uses different words for the same two mechanisms:

Salesforce (Data 360) says query federation versus file federation: the clerk versus the book room (Salesforce Trailhead).
Databricks says query federation versus catalog federation, where the query is "only executed using Databricks compute" (Databricks).
Snowflake does not use either label. Its part of the story is letting outside engines read its Iceberg tables through Horizon Catalog (Snowflake).
Google BigQuery does not say federation at all on its side. It calls the connection linked datasets, through BigQuery Omni (Google Cloud).

Look at the first two rows. Both vendors say query federation, but the second word differs. Read their docs back to back and you will assume catalog federation and file federation are the same thing. They are close, but not the same: both skip the warehouse engine, but one works through a catalog crawl and the other reads Iceberg files.

An architect reviewing Salesforce's own guidance credited the federation-type breakdown while noting "qualms about the product naming conventions" (Luke Ambrosetti). If a practitioner at that level pauses on the vocabulary, assume your vendor's account team will blur it too.

The names change faster than the technology. Salesforce renamed Data Cloud to Data 360 at Dreamforce 2025, effective October 14, 2025, stating the "functionality and content remains unchanged" (Salesforce Trailhead). Data 360 now folds in Tableau, MuleSoft, and the pending Informatica acquisition (SiliconANGLE).

So hold on to the mechanics, not the product names. The real question is simpler: which of these modes does your warehouse support? That is where the three platforms stop looking the same.

Snowflake vs Databricks vs BigQuery: what your warehouse actually supports

Most articles treat the three warehouses as if they were the same. They are not. The warehouse you already run decides which mechanisms you get.

Warehouse	Query federation	Storage-layer federation (file / catalog)	Data sharing (data out)	Constraint to know
Databricks	Yes	Yes: catalog federation, on Databricks compute	Yes, into Unity Catalog	Federation is read-only
Snowflake	Yes	Yes: Horizon Catalog + Apache Polaris (GA Feb 2026)	Yes	Only tables synced to the right catalog are reachable
BigQuery	Yes	Not offered	Yes, via BigQuery Omni linked datasets	No Government Cloud; structured data only

Databricks supports the most. Lakehouse Federation offers both query federation and catalog federation, and its supported-source lists name Snowflake and Salesforce Data 360 explicitly (Databricks). Data 360 file sharing into Databricks Unity Catalog adds the reverse direction. If your warehouse is Databricks, every mechanism is available.

Snowflake lets outside engines read its managed Iceberg tables through Horizon Catalog, which speaks the open Iceberg REST protocol (Apache Polaris is built in). That went generally available on February 6, 2026, using your existing Snowflake users, roles, and policies (Snowflake). The catch, which Ambrosetti flags: only tables synced to the right catalog can be reached this way (Luke Ambrosetti).

BigQuery is the odd one out, and here the difference gets real. Salesforce's own BigQuery connector lists its method as "Zero Copy (Query Federation, Data Share)," bidirectional, structured data only (Salesforce). File federation is not on the list. The same page adds two more limits: it is not available in Government Cloud, and on the BigQuery side the connection runs through BigQuery Omni linked datasets, not direct file reads.

Google's own docs are honest about what those linked datasets point at. Every Data Cloud object appears in BigQuery as a view, and those views point to "hidden tables that are stored in Amazon S3" (Google Cloud). Use BigQuery Omni materialized views to speed things up and you have made a local copy.

The same doc warns that INFORMATION_SCHEMA views "are synced regularly from Data Cloud and may be stale." That is where zero copy quietly stops being zero copy, documented in the vendor's own quickstart.

What zero copy costs, on both invoices

Zero copy is sold on one number: federation is cheaper than moving data. That is true on one invoice. If you own the budget, you need to see both invoices.

The official Salesforce Data Cloud rate card (August 2025) sets the multipliers per million rows, Production Batch: data federation or sharing accessed, 70 credits; data share out, 800 credits; batch ingestion through an external data pipeline, 2,000 credits (Salesforce Rate Card). Under the Flex Credits model, credits cost $500 per 100,000, or $0.005 each (Data 360 Pricing). The 70-versus-2,000 gap, roughly 28 to 1, is the number the pitch rests on.

Now the part that number hides. Those 70 credits meter the Salesforce side only. Under query federation, the external engine executes on its own compute and bills you separately, because both engines run (Databricks).

So the real comparison is not 70 versus 2,000. It is 70 credits plus your Snowflake or Databricks compute, against 2,000 credits with no external compute. File federation removes the second invoice by reading storage with Data 360's own engine (Salesforce Trailhead).

One footnote on Snowflake: even the storage-layer path can leave a small line on that invoice. When the read goes through Horizon's Iceberg REST Catalog API, Snowflake bills 0.5 Cloud Services credits per million calls, with billing scheduled to start in the second half of 2026 (Snowflake).

Operation (per 1M rows, Production Batch)	Credits	At $0.005 per credit	External warehouse compute?
Data federation or sharing, rows accessed	70	$0.35	Yes under query federation, billed separately; none under file federation
Data share, rows shared out	800	$4.00	The reading warehouse pays its own compute
Batch ingestion, external data pipeline	2,000	$10.00	None

Salesforce's own pricing example shows the scale. For a Snowflake-based enterprise, the first-year list price totals $129,845, and the single line "Data Federation or Sharing Rows Accessed" runs to 114 billion rows accessed, 7,984,375 credits, $39,922 (Salesforce). Federation is the second-largest cost line in the vendor's own example, not a rounding error.

The break-even point depends on how often you query. No one publishes a single break-even number, so work it out per workload. Federation's per-row rate is low but charged on every access.

An independent analysis states it directly: federation is "cheaper at small volumes" and "wildly more expensive when an autonomous agent queries 50 million rows in a loop" (Revanth). Analysts query selectively; agents query relentlessly. A federation setup tuned for dashboards will surprise you the first time an AI workflow hits it. One more thing to watch: "acceleration." Ambrosetti points out it is caching, meaning a copy, and that copy has a storage cost the comparison tables leave out (Luke Ambrosetti).

"Your data never leaves" is true and incomplete

The data does stay in your warehouse. That part is true. What the pitch skips is a different question: who enforces your access rules. The answer changes with the mechanism.

Salesforce engineering says it plainly: "Query Federation naturally relies on the remote warehouse's governance controls because that platform executes the query. File Federation shifts more responsibility toward Data 360 because compute operates closer to storage" (Salesforce Engineering). Under query federation, your warehouse enforces the rules. Under file federation, Data 360 does.

A working architect puts it more sharply. When file federation reads files directly, it bypasses the source platform's compute engine, and with it the governance layer that engine enforces. Ambrosetti's conclusion: it "requires you to duplicate and maintain a second governance model entirely within Data Cloud" (Luke Ambrosetti).

Your Snowflake Horizon or Databricks Unity Catalog policies do not follow the data when something reads around the engine that applies them. For a CIO in a regulated industry, that is the sentence that matters. It is the opposite of the "better governance" the category is sold on.

It is not all bad news, but be precise about it. Snowflake can enforce masking policies, tag-based masking, and row access policies on Iceberg tables queried from Apache Spark, as long as the read goes through the governed Horizon Catalog path, generally available since January 27, 2026 (Snowflake).

The rules hold when the read goes through the governed catalog path; Spark is the documented case so far. They do not hold when an engine reads raw files outside that path. Know which path you are on before you promise anything to a compliance officer.

The credential model is the reassuring part. File federation never takes permanent access to your storage. Access "flows through the catalog layer, which provides temporary credentials for specific requests and limited periods of time" (Salesforce Engineering). Access is granted per request, for a limited time, never permanently. In my assessment, that credential design is the strongest security argument for the pattern, stronger than "the data never leaves," because it answers what an auditor asks.

How to choose, by warehouse and query frequency

Two things decide this. First, which warehouse you run: that sets which mechanisms you can use. Second, how often the query runs: that decides whether paying per access beats copying once.

Your warehouse	Query fires occasionally (ad hoc, weekly reports)	Query fires constantly (live dashboards, agents)
Databricks	Federate through the storage layer, single engine	Ingest first; federation pays per access
Snowflake	Federate: storage path via Horizon Catalog where synced, else query federation	Ingest first; watch the second invoice under query federation
BigQuery	Query federation, the only zero-copy path in	Ingest first; no storage-layer fallback exists

Use file federation, or catalog federation on Databricks, when your warehouse offers it. Salesforce recommends file federation "whenever it's supported," and Databricks calls catalog federation "more cost-effective and performance-optimized than query federation" (Salesforce Trailhead, Databricks). Fall back to query federation only where that path does not exist, which for now means BigQuery (Salesforce).

Copy the data in when you query it constantly and need fast answers. Federation pays a network round trip, and often remote compute, on every single query. An AI agent that scans the same table thousands of times a day multiplies that cost thousands of times (Revanth). One limit that catches teams late: both federation modes in Databricks are read-only (Databricks). If you need to write results back, federation is not your mechanism.

One bigger test sits above all of this. Before you sign, ask what you can take with you if you leave in 18 months. If the answer is your raw data, transformations, and lineage in open formats on infrastructure you control, the pitch has merit.

If the answer is that you can export the data but the agents and the cache layer stay behind, you are buying what that analysis calls "a higher-priced ETL with the receipts hidden" (Revanth). Treat zero copy as a capability inside your architecture, not a replacement for it.

Common questions

What is zero-copy architecture? A pattern for using data where it already lives, without duplicating it. Instead of an ETL pipeline that extracts and loads a copy, the consuming system reads the source through metadata references or a live query (Salesforce Trailhead).

How does zero copy work? Through one of three mechanisms: query federation, where the source engine runs the query; file federation, where the consuming platform reads the source's Iceberg storage directly; and data sharing, where the source exposes governed objects for an external system to query in place (Salesforce Trailhead).

What is the difference between query federation and file federation? Query federation runs on the external engine and can bill you for external compute; every platform supports it. File federation runs on the consuming platform's own compute against the storage layer, avoids external compute fees, and is not supported everywhere (Salesforce Trailhead).

Does zero copy work with Snowflake, Databricks, and BigQuery? Yes, but not identically. Databricks supports query and catalog federation plus sharing; Snowflake exposes tables to external engines via Horizon Catalog; BigQuery supports query federation and data share only, with no file federation and no Government Cloud availability (Databricks, Salesforce).

Is zero copy actually cheaper than ETL? At low query volumes, yes: 70 credits per million rows federated against 2,000 for batch ingestion. At high, repeated query volumes, federation can cost more once you count the external compute it triggers on every access (Salesforce Rate Card, Revanth).

Who pays for the compute when you federate a query? Under query federation, you pay both: Salesforce credits plus your external warehouse's compute, because both engines run. File federation removes the external compute bill by reading storage with Data 360's own engine (Databricks).

The one line to take away

Zero copy tells you where the data lives. It does not tell you where the compute runs, who pays for it, or who enforces your policies, and those three answers change with the mechanism and the warehouse. Before you sign off, ask which mechanism, on which platform, at what query frequency.

For teams weighing a zero-copy connection against a migration, our team can map the mechanism, cost, and governance tradeoffs to your specific warehouse. Book an architecture consult.