Data 360
Connecting Data 360 to Snowflake with zero copy: federation in, sharing out
Snowflake is where the zero-copy pattern got famous, and it's the connector our BigQuery and Redshift write-ups kept pointing at without walking through. Here's the Snowflake bridge end to end: federation in versus sharing out, the three ways to authenticate now that Salesforce-IdP removes the long-lived key, the warehouse-ownership step that blocks half of first setups, and why Iceberg makes the share-back cleaner than the AWS path.
Every zero-copy explainer opens with Snowflake, the pairing that made the idea famous, then documents BigQuery or Redshift instead. Our own BigQuery and Redshift walkthroughs both did it, each treating the Snowflake bridge as the thing you already knew. This is the one that walks it.
The reason it’s worth its own post now: the Snowflake connector changed. The old setup made you generate an RSA key pair and paste a private key into Salesforce, which worked and which security teams hated. Salesforce added identity-provider authentication, so you can connect without a long-lived credential living in the org at all.
Two things to settle before you touch Setup, and they decide everything after: which direction you need the data to move, and how Salesforce should prove who it is to Snowflake. Get those two right and the rest is filling in an account URL.
Federation in and sharing out are two different features
“Zero copy with Snowflake” names two capabilities pointing opposite ways. People blur them constantly, and the setup, the direction of trust, and the failure modes differ for each.
Federation (Snowflake into Data 360). You register a Snowflake table as an external source. At read time, Data 360 queries Snowflake live and uses the rows without ever storing a copy. Snowflake stays the system of record.
This is what most teams want first. There’s a table in Snowflake, an order history, a product-usage score, a model output from the data-science team, that needs to ground an agent or unify into a profile without standing up another batch pipeline.
Sharing (Data 360 out to Snowflake). The reverse. You expose unified Data 360 tables so Snowflake can query them in place, again with nothing copied. Now an analyst runs Snowflake SQL that joins your warehouse data against a live Salesforce unified profile.
Decide the direction before anything else. Federation reads Snowflake into Data 360 on demand; sharing exposes Data 360 out to Snowflake. They are set up in different places and fail for different reasons, and “we want zero copy with Snowflake” is not yet a spec.
Most builds start with federation, so that’s the one we’ll stand up in full, then cover the share-back, which Snowflake’s Iceberg support makes unusually clean.
The auth choice is the part that changed
Federation needs Salesforce to authenticate to your Snowflake account. There are three ways, and the newest is the one to reach for.
Salesforce IdP authentication is the credential-free path, and the one to reach for. You toggle Use Salesforce IDP Auth on the connection, Data 360 generates an external ID, and you configure Snowflake to trust tokens minted by your Salesforce org.
No password or private key is stored in Salesforce. You revoke access on the Snowflake side by dropping trust rather than rotating a secret. If your security team has ever objected to a pasted key, this is the answer to point them at.
Key-pair authentication is the original path, still supported. You generate an RSA public/private key pair, attach the public key to a Snowflake integration user, and paste the private key into the connection. Two details trip people: the connector does not accept an encrypted private key, and you paste the key body only, without the BEGIN/END header and footer lines.
OAuth 2.0 is the third option, useful when you’re already brokering Snowflake access through an OAuth provider.
Whichever you pick, you also give the connection your Snowflake account URL and choose the warehouse and database. Which brings up the step that blocks more first-time setups than the auth does.
The warehouse-ownership step nobody expects
Data 360 runs its federated queries through a Snowflake virtual warehouse, and that warehouse needs to be usable by the role Data 360 connects as, not owned by a Snowflake account admin.
In Snowflake, create a warehouse (Admin → Warehouses → + Warehouse), pick a size, and then transfer its ownership to a non-administrative role, the role your integration user or IdP mapping uses. Skip that transfer and the connection validates but queries fail later with a permissions error that doesn’t obviously point back at warehouse ownership. Do it up front.
Right-size the warehouse while you’re there. Every federated read is Snowflake compute you pay for on the Snowflake side, so an oversized warehouse spending on idle auto-resume is a cost you’ll see on Snowflake’s bill, not Salesforce’s.
Standing up federation, step by step
With the direction and auth decided, the path is short.
- In Data 360, go to Data Cloud Setup → External Integrations → Other Connectors → New and choose Snowflake. Enter the account URL and select your authentication method.
- For IdP auth, toggle Use Salesforce IDP Auth, copy the external ID, and set up the matching trust in Snowflake. For key-pair, paste the unencrypted private key body of your integration user. Save, and Data 360 validates the connection.
- Create the data stream. Open the Data Streams tab, click New, and pick the Snowflake tile. Choose your connection and database, and Data 360 reads the schema of the connected Snowflake objects.
- Map only the tables you need. Every federated object is one Data 360 will issue a live query against at read time. The forty staging tables you don’t map cost you nothing. This is the same Data Lake Object versus Data Model Object discipline as any other source: the mapping step is where you decide what the rest of the platform can see.
If validation fails, suspect the trust configuration or the warehouse role before anything exotic, and check the account URL for a stray region suffix. Those three account for most first-attempt failures.
What “live query” changes about your design
Federation is a live read, and that single fact reshapes the trade-off against copying data in. It’s the reason to use it and the thing that bites teams who treat a federated table like a local one.
The upside is freshness with no duplication. A federated Snowflake table is never stale, because there’s no copy to go stale. You don’t store the data twice, and there’s no pipeline to break at month-end.
The cost is that every read is a round trip to Snowflake, priced in Snowflake compute. A federated join over a poorly clustered table is slow the same way it’s slow in Snowflake, and if a segment build, a calculated insight, or an agent’s grounding call hammers a federated object, you feel it as latency and as Snowflake spend.
The rule that keeps you out of trouble:
- Federate data that’s large, changes often, and is queried selectively, where a live read of a filtered slice beats copying the whole table on a schedule.
- Ingest (copy in) data you’ll query repeatedly at high volume in latency-sensitive processes, where a round trip per read costs more than the storage.
That’s the same batch-versus-live judgment that runs through the credit bill. Federation isn’t free because it skips the copy. You trade storage for per-query compute and latency, and the trade is only good when the access pattern fits.
Sharing back, where Iceberg earns its keep
The reverse direction is where Snowflake is nicer than the AWS path. Data 360 stores its data in the open Apache Iceberg table format, and Snowflake reads externally managed Iceberg tables natively.
To share out, go to Data Share Targets, click New, and pick the Snowflake tile to expose the Data 360 tables you choose. On the Snowflake side they land as externally managed Iceberg tables an analyst can query like any other, joined against your warehouse data, with nothing copied.
Contrast that with the Redshift share-out, which routes through the AWS Glue Data Catalog and Lake Formation. Because both Data 360 and Snowflake speak Iceberg, the share is a more direct handshake with fewer moving parts.
If your open-table gravity lives elsewhere, in an S3 lake or a catalog another team curates, the more general bridge is Iceberg file federation. The Snowflake connector is the direct route when Snowflake specifically is the warehouse.
One roadmap note, stated as roadmap. Salesforce and Snowflake have signalled a reimagined version of this connector experience. Treat anything you read about a “v2” as forward-looking, and build against the connector that’s documented and GA today rather than a slide.
Where this leaves the “Data 360 or Snowflake” question
If you’ve read our Data 360 versus Snowflake piece, this connector is the practical proof of its argument. The choice was never which warehouse wins. Zero copy means your customer data can stay in Salesforce and your analytical data can stay in Snowflake, and each can query the other in place.
Federation reads Snowflake into Data 360 live over your chosen auth, with nothing copied. Sharing exposes Data 360 out to Snowflake as Iceberg tables, again with nothing copied.
Decide the direction first, use Salesforce-IdP auth so no key lives in the org, transfer that warehouse’s ownership before you wonder why queries fail, and federate only what you’ll use. Wiring warehouses into Data 360 so an agent grounds on live data instead of a stale export is the core of our integration and Data Cloud work.
Understanding the basics
Does Data 360 have a zero-copy connector for Snowflake?
Yes. Data 360 federates Snowflake tables, running live queries against your Snowflake account at read time without storing a copy, and it also shares unified Data 360 data out to Snowflake as externally managed Apache Iceberg tables that Snowflake can query in place. It’s the Snowflake counterpart to the BigQuery and Redshift zero-copy bridges, and because Data 360 stores data in Iceberg, the share-back to Snowflake is a direct open-table handshake rather than a catalog-brokered one.
How does the Data 360 Snowflake connector authenticate?
Three ways. Salesforce IdP authentication is the newest and avoids storing any long-lived credential: you toggle Use Salesforce IDP Auth, Data 360 issues an external ID, and Snowflake is configured to trust tokens from your Salesforce org. Key-pair authentication is the original method, where you attach an RSA public key to a Snowflake integration user and paste the unencrypted private key body into the connection. OAuth 2.0 is also supported. All three also need your Snowflake account URL and a warehouse and database to run against.
Why do my Snowflake federated queries fail after the connection validates?
The most common cause is warehouse ownership. Data 360 runs federated queries through a Snowflake virtual warehouse, and if that warehouse is owned by an account-admin role rather than the non-administrative role Data 360 connects as, the connection can validate while queries fail with a permissions error. Create the warehouse and transfer its ownership to the role your connection uses before running a stream. Check the account URL and the auth trust configuration next.
When should I federate a Snowflake table instead of copying it into Data 360?
Federate when the data is large, changes often, and is queried selectively, so a live read of a filtered slice is fresher and cheaper than copying the whole table on a schedule. Ingest, or copy in, when you’ll query the data repeatedly at high volume in latency-sensitive processes, where a round trip to Snowflake on every read costs more than the storage. Federation trades storage cost for per-query Snowflake compute and latency, so it’s the right call only when the access pattern favors freshness over repeated bulk reads.
Standing up a Snowflake bridge and stuck on the IdP trust or the warehouse role, or weighing what to federate versus ingest? Talk to us. Wiring warehouses into Data 360 so an agent can ground on live data without another brittle pipeline is a normal week for our integration team.
