How Salesforce Data Cloud Zero Copy Actually Works With Snowflake

Your data engineer says the customer data already lives in Snowflake — all of it, clean, modeled, production-ready.

Your data engineer says the customer data already lives in Snowflake — all of it, clean, modeled, production-ready. Your architect wants to copy it into Salesforce Data Cloud. You’re running the mental math on storage costs, pipeline maintenance, and the inevitable sync drift between two copies of the same truth. This is the exact problem Zero Copy was built to kill.

In Q3 FY2026, Salesforce Data Cloud ingested 32 trillion records in a single quarter. Of those, 15 trillion — nearly half — flowed through Zero Copy connectors, a 341% year-over-year surge. That ratio tells you something important: nearly half of all enterprise data entering Data Cloud never actually enters Data Cloud. It stays exactly where it is, in Snowflake or Databricks or BigQuery, and gets queried in place. No ETL job. No second copy. No 2 a.m. pipeline failure that leaves your Agentforce segments stale.

But here’s the thing most practitioners miss: “Zero Copy” is not one mechanism. It’s two completely different architectures — Query Federation and File Federation — and using the wrong one for your workload is how you end up paying Snowflake compute bills you didn’t expect while solving a problem Salesforce told you was free. This is the guide that breaks both apart.

TL;DR

→ Salesforce Data Cloud Zero Copy has two inbound modes. Query Federation sends a SQL query to Snowflake’s compute, which runs it and returns the result — you pay Snowflake credits for every query. File Federation reads your Iceberg files directly using Data Cloud’s own engines — no Snowflake compute billed at all. Salesforce now recommends File Federation wherever the platform supports it.

→ The outbound direction — Data Sharing — lets external systems like Snowflake read Data Cloud’s enriched outputs (unified profiles, segments, calculated insights) without copying them out. Snowflake uses Secure Data Sharing; Databricks uses Delta Sharing and Unity Catalog.

→ Apache Iceberg is the technical layer that makes File Federation possible. Because both Data Cloud and Snowflake support Iceberg as an open format, Data Cloud can read Snowflake Iceberg tables directly at the storage layer — without a proprietary connector and without Snowflake’s compute firing.

→ Query Federation works for all Snowflake table types. File Federation requires your Snowflake tables to be Iceberg-backed. If they’re native Snowflake tables, you’re on Query Federation and paying Snowflake for each read.

→ The acceleration schedule for a Data Stream can run as frequently as every 15 minutes for incremental refreshes. Understand this schedule before you configure — it’s where your Snowflake credit bill comes from if you’re on Query Federation.

The architecture: two modes, one brand name

Comparison chart of Query Federation and File Federation architectures in Snowflake, showing differences in data cloud access, compute layer, storage, and billing, with Query Federation charging compute credits and File Federation not charging.

Query Federation delegates compute to Snowflake and bills you for it. File Federation uses Data Cloud’s own engines against the storage layer — Snowflake compute never runs.

Underneath the marketing, Zero Copy Data Federation splits into two fundamentally different execution models.

Query Federation is the JDBC model. Data Cloud formulates a SQL query, applies predicate pushdown — filters, aggregations, joins — and ships it over a JDBC connection to Snowflake. Snowflake’s engine executes it against its own tables and returns only the result set. This is efficient because query pushdown ensures Snowflake ships back a small answer rather than a full table scan. It’s also real compute: Snowflake bills you for every query Data Cloud fires, just as if one of your analysts had run it. If your Data Stream acceleration is set to refresh every 15 minutes against a large table, you’re firing 96 Snowflake queries a day on that one object.

File Federation is the Iceberg model. Data Cloud reads your data files directly from the storage layer — the same Parquet files that Snowflake manages — using Data Cloud’s own engines (Spark, Hyper, and Trino, routed automatically by workload type). Snowflake’s compute is never involved. No Snowflake credits fire. You pay Data Cloud’s read costs, not Snowflake’s query costs. The mechanism that makes this possible is Apache Iceberg: because both Snowflake and Data Cloud support Iceberg as an open table format, Data Cloud can read the Iceberg manifest and data files directly without any proprietary connector. The constraint is that your Snowflake tables must be Iceberg-backed. Native Snowflake tables are not eligible; they fall back to Query Federation.

Salesforce now explicitly recommends File Federation over Query Federation wherever the external platform supports it. File Federation is GA for Databricks and generic Iceberg catalogs. For Snowflake specifically, File Federation requires Snowflake-managed Iceberg tables exposed through the Iceberg REST Catalog.

Setting up Zero Copy with Snowflake: what you actually configure

Before you touch any Salesforce UI, the Snowflake side needs preparation. You create a dedicated warehouse, an integration user, and a key-pair authentication setup. The integration user gets scoped grants — at minimum USAGE on the database and schema, SELECT on the tables you’re federating. The key-pair (public/private RSA) is what Data Cloud uses for the JDBC connection in Query Federation, or for the Iceberg REST catalog handshake in File Federation.

On the Salesforce side, the flow in Data Cloud Setup is: create a connector (Snowflake connector type), supply the account URL and credentials, then create a Data Stream on top of that connector. The Data Stream is where you select which Snowflake objects to surface in Data Cloud, map them to Data Cloud object types, and configure the acceleration schedule.

The acceleration schedule deserves careful thought. “Live query” means Data Cloud queries Snowflake at request time — zero persistence, but every Agentforce or segmentation operation that touches this object fires a Snowflake query. Caching (available on Query Federation only) persists data in Data Cloud’s lake and reads from there, which lowers per-operation latency and Snowflake credit consumption on repeated reads. File Federation skips this choice entirely: it’s always live against the storage layer, with no caching option needed because the file-read cost is already low.

The direction most tutorials skip is outbound — Data Cloud pushing its outputs to Snowflake rather than reading from it. Once Data Cloud has unified your customer profiles, resolved identities across touchpoints, scored propensity, and built segments, those enriched objects become queryable by Snowflake without any ETL back-out.

Salesforce uses Secure Data Sharing for the Snowflake outbound direction: Data Cloud creates a share that Snowflake mounts as an external object, and your Snowflake analysts query unified profiles and calculated insights as if they were native Snowflake tables — with live data, no copy, no maintenance pipeline. At 800 credits per million rows on the Data Cloud side, this is costlier than inbound federation, but it eliminates outbound pipeline maintenance entirely and ensures analysts are always reading the unified truth rather than a stale export.

Apache Iceberg: why this works without a proprietary connector

The reason File Federation doesn’t need a vendor-specific connector is worth understanding, because it’s also why the integration has limits. Data Cloud internally manages 4 million Apache Iceberg tables spanning 50 petabytes of data, and its query engines — Spark, Hyper, Trino — natively speak the Iceberg table spec. When a Snowflake table is Iceberg-backed, its data is Parquet files with Iceberg metadata in shared object storage. Data Cloud’s engines can read that metadata, identify the data files, and scan them directly — the same way Databricks or Trino would. No Snowflake layer in the request path.

This also explains the limitation: native Snowflake tables use Snowflake’s internal micro-partition format, which is not Iceberg. Data Cloud can’t read that format directly, so it falls back to Query Federation — going through Snowflake’s JDBC interface and paying Snowflake compute. If your organization hasn’t migrated tables to Snowflake-managed Iceberg yet, every Zero Copy read is Query Federation regardless of what your architecture diagram says.

When Zero Copy is the wrong answer

Zero Copy is not always the right architecture, and the 341% adoption surge doesn’t mean it’s universally appropriate. Three cases where you’re better off ingesting into Data Cloud properly:

Complex transformations before Data Cloud use. If the data needs significant modeling or enrichment before it’s useful in segmentation or Agentforce contexts, federating raw Snowflake tables means pushing that compute burden onto every Data Cloud operation. Ingesting clean, pre-modeled data is faster and cheaper at query time.

High-frequency access patterns. Query Federation on a frequently-queried object with a short acceleration schedule fires Snowflake queries continuously. At a certain access frequency, ingestion and native Data Cloud storage is cheaper than accumulating Snowflake credits on every segmentation job.

Regulatory data residency requirements. Zero Copy keeps data in its source system and queries it in place. If your regulatory requirements mandate that Salesforce-accessed data must reside in a Salesforce-controlled environment, Zero Copy may not satisfy that requirement — confirm with your legal and compliance teams, because “data never moves” has a specific legal meaning in some jurisdictions.

The gotchas nobody warns you about

Type compatibility is a real mapping problem. When Data Cloud pulls a Snowflake table into a Data Lake Object via Query Federation, it maps Snowflake types to Data Cloud types. VARIANT, GEOGRAPHY, and some timestamp precision types don’t always map cleanly. Verify your field types in the Data Stream configuration before you build segments on top of a federated table — a silently miscast timestamp can produce wrong results without an obvious error.

Private Connect for VPC-locked Snowflake. If your Snowflake account is locked down in an AWS VPC or Azure VNet private endpoint, standard Zero Copy connectivity won’t reach it. You need Private Connect for Data Cloud enabled, which requires additional network configuration on both sides and is not automatic.

Grants on future objects don’t auto-extend. Zero Copy connects to the Snowflake objects you grant at setup time. New tables added to the same schema are not automatically federated — use GRANT … ON FUTURE TABLES IN SCHEMA proactively during setup so new objects are automatically covered.

The acceleration checkbox. When you create a Data Stream, enabling the “Enable acceleration” checkbox triggers the caching mechanism. Caching behavior and billing implications differ between Query and File Federation — read the settings for your connector type before enabling.

The one principle

Zero Copy has two completely different execution models — Query Federation bills your Snowflake account every time Data Cloud reads, File Federation uses Data Cloud’s own engines against Iceberg storage and doesn’t. Know which one you’re on, because your Snowflake credit bill will. If your Snowflake tables are Iceberg-backed, push toward File Federation. If they’re not, that’s the migration decision hiding inside your “zero copy” architecture.