Salesforce Data 360 vs. Snowflake: the wrong question, and how to use both

The meeting usually goes the same way. The data team has run Snowflake for years; it holds the company’s revenue models, product telemetry, and every dashboard the executives trust. Then the Salesforce account team pitches Data 360 — the platform renamed from Data Cloud in October 2025 — as the data foundation for Agentforce. Someone in procurement squints at both line items, sees two consumption-priced platforms that store data and answer queries, and asks the question that derails the next quarter: which one should we keep?

It’s the wrong question. Snowflake is a general-purpose data platform; Data 360 is a customer-data activation and agent-grounding layer bolted to your CRM. They overlap just enough to look like rivals on a slide and differ enough that replacing either with the other goes badly. Salesforce and Snowflake evidently agree — they’ve spent two years building zero-copy integration between the two products precisely so customers don’t have to choose.

This post lays out what each platform is actually for, where the overlap is real and where it misleads, how the bidirectional zero-copy bridge works, what both credit models do to your budget, and the reference architecture we recommend when a client owns both.

Two platforms built for different jobs

Start with what each product would be if the other didn’t exist.

Snowflake is a cloud data platform organized around three independently scalable layers: storage (data held in compressed, columnar micro-partitions, with support for Apache Iceberg and hybrid tables), compute (virtual warehouses — isolated clusters you spin up per workload), and a cloud services layer that handles metadata, optimization, and security. On top of that sit workloads: data engineering with Snowpipe and dynamic tables, analytics, Snowpark for Python and ML, Streamlit apps, and Secure Data Sharing for live, no-copy collaboration across accounts and companies. It runs on AWS, Azure, and Google Cloud. Nothing about it assumes your data is about customers. Finance ledgers, IoT sensor streams, supply-chain tables — Snowflake is indifferent, which is the point.

Data 360 assumes exactly the opposite. Everything in it is organized around one entity — the customer — and one pipeline: ingest data from CRM, commerce, service, and external sources; map it to a standard data model; run identity resolution to merge duplicate people into unified profiles; compute segments and calculated insights on those profiles; then push the results into the systems that act on them — Marketing Cloud journeys, ad platforms, Flow automations, CRM record pages, and increasingly the retrieval indexes that ground Agentforce agents at runtime. We’ve walked through that pipeline stage by stage in our explainer on what Data 360 actually is; the short version is that it’s an opinionated machine for turning fragmented customer records into activated, agent-ready context.

One platform is a workbench. The other is an assembly line. Asking which is better is asking whether a workshop needs tools or products.

Where Data 360 and Snowflake genuinely overlap

The confusion isn’t stupid — the overlap is real, and it’s grown.

• Both store data at scale. Data 360 is built lakehouse-style on open table formats rather than inside the classic Salesforce transactional database, which is why it can hold event volumes that would flatten a CRM org. Seen from a distance, that looks like a warehouse.
• Both answer SQL-shaped queries. Snowflake is one of the best analytical query engines available. Data 360 exposes query APIs and powers segments and insights over billions of rows. “It can query my data” is true of both.
• Both do ML and AI. Snowflake ships Cortex, including Cortex Analyst for structured data and fully managed Cortex Agents that plan, call tools, and answer over governed data. Data 360 feeds Einstein predictions and grounds Agentforce. Two agent stories, one in each brochure.
• Both are consumption-priced. Credits in, workloads out, and a finance team that wants to know why there are two of these bills.

Here’s why the overlap misleads: shared capabilities are not shared jobs. Snowflake having an agent framework doesn’t give it native awareness of your Salesforce cases, Flows, and journeys. Data 360 holding billions of rows doesn’t make it a place to run arbitrary finance analytics — its meters and its data model would fight you the whole way. Feature checklists converge; centers of gravity don’t.

What each does that the other doesn’t

This is the comparison that actually matters, so it deserves specifics.

What Data 360 does that Snowflake doesn’t do out of the box. Identity resolution is configuration, not a build: you define match and reconciliation rules and the platform produces unified profiles with lineage back to every source record. Segmentation and activation are native — a segment built today can be publishing to Marketing Cloud, Meta, or a Flow trigger this afternoon, with consent handled in the same model. And it’s the sanctioned grounding layer for Agentforce: retrievers, search indexes, and the Einstein Trust Layer sit on Data 360, not on your warehouse. Snowflake can support all of these outcomes — its marketing pitch is the composable CDP, where identity, segmentation, and activation run on the platform via SQL, native apps, and reverse-ETL partners — but that’s an architecture you assemble and operate, not a product you switch on.

What Snowflake does that Data 360 shouldn’t attempt. General-purpose analytics across every domain of the business, not just customers. Heavy data engineering: transformation pipelines, dynamic tables, dbt workflows, semi-structured data wrangling. Data science and ML development in Snowpark with real compute isolation. BI serving for the whole company. And cross-company collaboration — Secure Data Sharing exposes live tables to partners without copying them, backed by a marketplace and clean rooms. Data 360 has no ambition to be any of that, and its rate card punishes anyone who tries to make it so.

	Snowflake	Salesforce Data 360
Primary job	General-purpose data platform: warehouse, engineering, ML, apps	Customer-data activation and agent grounding attached to CRM
Data model	Whatever you design; domain-agnostic	Opinionated customer model (DLOs mapped to standard DMOs)
Identity resolution	Build it — SQL, native apps, partner tools	Native match/reconciliation rules producing unified profiles
Segmentation & activation	Composable: reverse ETL and partner ecosystem	Native to Marketing Cloud, ads, Flow, CRM surfaces
AI / agents	Cortex Analyst, Search, and Cortex Agents over governed data	Grounding, retrievers, and trust controls for Agentforce
Analytics & BI	Core strength, company-wide	Customer insights and segments; not a BI backend
Cross-company sharing	Secure Data Sharing, marketplace, clean rooms	Data shares to warehouses; no marketplace
Pricing meters	Credits per second of compute, plus storage per TB	Credits per million rows, per usage type
Wrong use	Being your CRM’s activation and consent layer	Being your enterprise warehouse of record

If your problem is “our analysts can’t model the business,” Snowflake wins and it isn’t close. If your problem is “our customer data is fragmented and nothing downstream — journeys, service, agents — can act on it,” that’s the job Data 360 was built for. Most enterprises we work with have both problems. Which is why the vendors built a bridge.

Zero copy: the bidirectional bridge between them

The integration is the strongest evidence that “vs.” is the wrong frame. It went GA in two stages: data sharing out of Salesforce into Snowflake — the “Bring Your Own Lake” release in September 2023 — and then data federation from Snowflake into Data Cloud, completing the bidirectional loop in April 2024. Both directions are zero-ETL: no pipeline, no scheduled export, no second copy to reconcile.

Data in (federation). A Snowflake table mounts in Data 360 as an external data lake object — a pointer, not a copy. When a segment or query touches it, Data 360 pushes the query down to the source system’s engine, which executes it on a Snowflake warehouse and returns only results. The data is always current because there’s nothing to go stale. Setup is a key-pair-and-connector exercise Salesforce documents end to end.

Data out (sharing). The reverse direction turns Data 360 objects — unified profiles, calculated insights, segment membership — into a share your Snowflake account accepts and queries like any other database, authenticated over OAuth. Your analysts get the resolved customer identity graph in the tool they already live in:

-- Snowflake: unified profiles shared from Data 360, no export pipeline
SELECT ssot__Id__c, ssot__FirstName__c, ssot__LastName__c
FROM data360_share.unified.ssot__Individual__dlm
LIMIT 100;

This is not a fringe feature on either side. Salesforce engineering reported that over one six-month span, Data Cloud queried 4 trillion records in external systems while external platforms accessed 250 billion records back. The fine print matters, though — “zero copy” covers several mechanisms with different staleness and billing behavior, including cached acceleration that quietly reintroduces a copy. We’ve unpacked all of that in our practical guide to zero copy in Data 360, and it’s worth reading before you federate anything large.

A reference architecture: Snowflake as warehouse of record, Data 360 as the activation edge

Here’s the pattern we recommend when a client owns both platforms, and it starts from a principle: every dataset gets exactly one home, and the other platform gets a pointer.

Snowflake is the warehouse of record. All domains land there — finance, product telemetry, supply chain, and yes, customer events. Data engineering, modeling, BI, and data science happen there. If a table needs to be joined with non-customer data, governed for the whole company, or retained for years, it lives in Snowflake. Nothing about adopting Data 360 should demote the warehouse.

Data 360 owns only what activation needs. Its native contents are the things it uniquely produces: the mapped customer model, identity resolution output, consent, segments, calculated insights, and the retrieval indexes that ground agents. Salesforce CRM data flows in through the internal connector — which, per the current rate card, consumes no credits — and everything else arrives by decision, not by default.

Federate the reference data, ingest the hot paths. Warehouse tables that enrich profiles or feed occasional segments — purchase history, propensity scores, product usage rollups — stay in Snowflake and federate in via zero copy. Data that drives real-time features or gets scanned constantly by identity resolution and segmentation is a candidate for ingestion or acceleration instead, because live queries against your warehouse on every segment refresh have both latency and cost consequences. Co-locating the two platforms’ regions keeps egress and latency out of the equation.

Share the resolved customer back to Snowflake. Unified profiles and segment membership flow out through the data share, so churn models, LTV analysis, and executive dashboards are built on the same resolved identity the CRM and the agents use. This closes the loop that makes the whole design worth it: Snowflake computes on the best available customer picture, and its outputs — scores, cohorts, features — federate back in to drive activation.

The anti-patterns are the same design run backwards. Bulk-ingesting the warehouse into Data 360 “so it’s all in one place” burns credits to create a worse copy of Snowflake. Rebuilding company-wide BI on Data 360 queries misuses an activation layer. And running two disconnected customer models — one resolved in Data 360, one modeled in Snowflake — guarantees the numbers never match. Deciding which datasets sit on which side of the line is most of the design work, and it’s exactly the kind of question a data and AI strategy engagement exists to settle before contracts get signed.

The honest cost discussion: two credit meters on one workload

Both platforms bill in credits. The units could hardly be more different, and the architecture above only works financially if you understand both meters.

Snowflake meters time. Virtual warehouses bill per second, with a 60-second minimum, whenever they’re running; storage is a flat monthly rate per terabyte; cloud services are free until they exceed 10% of daily warehouse consumption. Credit prices vary by edition and region — but as a rough illustration at common list rates of about $2 per credit and $23/TB storage, a 65 TB deployment with moderate compute lands somewhere around $10,400 a month. Costs scale with how long compute runs, so the classic failure mode is warehouses idling without auto-suspend.

Data 360 meters rows and actions. The published rate card charges per million rows per usage type, and the spread is enormous: batch ingestion of external data runs 2,000 credits per million rows (5,000 streaming), zero-copy federation 70 credits per million rows accessed, data shares out 800 credits per million rows shared, queries just 2 — and profile unification 100,000 credits per million rows processed. At $500 per 100,000 credits, identity resolution is the line item that surprises people: unifying a million rows costs about $500 each time the ruleset runs across them, which is why rule changes that trigger re-unification deserve change control. Salesforce simplified the scheme in early 2026 — consolidating credit types and making ingestion from its own clouds free — but the per-usage-type structure remains, tracked in Digital Wallet.

Now the part neither sales deck volunteers: federation bills on both meters at once. A live-query segment refresh against a federated Snowflake table consumes Data 360 credits for rows accessed and Snowflake credits for the warehouse that executes the pushdown. That’s usually still far cheaper than maintaining pipelines and duplicate storage — but “zero copy” is not zero cost, and an unfiltered segment scanning a billion-row federated table will prove it on two invoices in the same month. Budget both sides, set resource monitors in Snowflake and consumption alerts in Digital Wallet, and revisit the federate-or-ingest call per table once real usage data exists.

Stop comparing platforms; start assigning jobs

The bake-off framing persists because both vendors sell ambitiously and procurement needs line items to compare. But two years of joint engineering — a bidirectional, GA, zero-ETL bridge that each company promotes on its own blog — tell you how the vendors themselves see it. Snowflake isn’t trying to be your CRM’s consent-aware activation layer. Salesforce isn’t trying to host your finance team’s models. The products are converging on features and diverging on jobs.

So reframe the evaluation. Not “Data 360 vs. Snowflake” but: which datasets need company-wide analytics, engineering, and governance — that’s warehouse work. Which need identity resolution, segmentation, consent, and agent grounding inside the Salesforce estate — that’s activation work. What crosses the boundary, in which direction, and on whose meter? Run the decision that way and the answer for most Salesforce-plus-Snowflake enterprises is boringly clear: keep Snowflake as the warehouse of record, scope Data 360 to the customer-activation and agent surface, connect them with zero copy, and police both credit meters.

Teams that internalize this stop having the platform argument and start having better ones — about which tables deserve federation, which segments justify their scan costs, and what an agent actually needs to know about a customer at runtime. Those questions have answers you can test. “Which platform wins?” never did.

Understanding the basics

Is Salesforce Data 360 a replacement for Snowflake?

No. Data 360 is a customer-data activation and agent-grounding layer attached to Salesforce CRM: it unifies customer identities, builds segments, and grounds Agentforce agents. Snowflake is a general-purpose data platform for warehousing, analytics, data engineering, and ML across every business domain. Data 360 is not designed to be an enterprise warehouse of record, and Snowflake doesn’t natively provide CRM-connected identity resolution or activation. Most enterprises that own both should connect them rather than choose.

Does Data 360 copy my Snowflake data?

Not by default. Zero-copy federation mounts Snowflake tables as external objects in Data 360 and pushes queries down to Snowflake for execution, so data stays in place and is always current. The exception is cached acceleration, which materializes a scheduled copy inside Data 360 for performance — useful, but it reintroduces staleness and ingestion-style metering. The bridge is bidirectional: Data 360 can also share unified profiles and insights back into Snowflake without an export pipeline.

Which is cheaper, Data 360 or Snowflake?

They meter different things, so a direct price comparison rarely means much. Snowflake bills compute per second plus flat storage per terabyte; Data 360 bills credits per million rows per action, from 2 credits for queries to 100,000 for profile unification, at $500 per 100,000 credits. The real cost question is architectural: federated queries consume credits on both platforms simultaneously, so cost control comes from deciding per table whether to federate, ingest, or leave data in the warehouse.

---

Trying to work out where your warehouse should end and Data 360 should begin? Talk to us — it’s what we do.