Zero-copy or ingest?

01 Where does the data live today?

A supported warehouse: Snowflake, BigQuery, Databricks or Redshift +3

These four are the platforms Data 360 can query in place. Everything else in this tool is downstream of that fact.

Another warehouse or lake 0

File federation reaches S3, Google Cloud Storage and ADLS when the data is in Iceberg format. Outside that, expect to land a copy.

An operational system or SaaS app -3

The four query-federation partners are warehouses, so an operational system is not among them. In practice the question stops being zero-copy or ingest and becomes which ingestion method.

02 How fresh must it be inside Data 360?

Weekly is fine +2

A relaxed freshness budget is what makes federation cheap: the acceleration cache can sit at the slow end of its range and repeat queries stop hitting the source.

Hourly to daily +1

Comfortably inside what both paths do. Neither the cache floor nor the batch refresh cadence is the binding constraint here.

Real time: it drives live journeys -3

Decisive on its own. This is the sub-second layer, and it forces ingest whatever the rest of the answers say.

03 Will it feed identity resolution and unified profiles?

No: analytics and reporting only +3

Nothing here joins to a person, so the whole unification question falls away and federation is unobstructed.

Some attributes, not the match keys 0

Attributes can hang off a profile that something else resolved. This is the answer that most often produces a hybrid split.

Yes: it carries the match keys -3

Decisive on its own. Match keys are what a resolution ruleset runs on, and it forces ingest whatever the rest of the answers say.

04 How heavily will Data 360 query it?

Occasionally: a few segments +2

Light query load is where we generally find federation wins on cost. Whether a share meters at all depends on where the query runs, which the recommendation below explains.

Moderately: daily segmentation 0

The band where the answer genuinely depends on the other five. Nothing about this load decides it either way.

Constantly: large segments, many refreshes -3

This is where we usually see federation economics invert. A copy is read from storage you already pay for; a share is queried live every time, and the recommendation below sets out who that lands on.

05 Does the data have to stay where it is?

Yes: residency or regulatory constraint +3

A hard constraint that federation satisfies and a copy does not. It is the one input here that is not about cost or speed.

Preferred, not required +1

A thumb on the scale rather than a constraint. It will not decide the answer on its own.

No constraint 0

Neutral. The decision comes down to freshness, identity and query load.

06 Who pays the warehouse compute bill?

Us: same budget, same owner +1

Federation moves cost rather than removing it. When the cost lands in the same budget, moving it is a real saving to reason about.

A different team -2

Federation spends someone else's budget on your segmentation. That is a conversation to have before the design, not after the invoice.

Data that carries identity match keys forces ingest, whatever the score.

Match keys are what an identity resolution ruleset runs on, and unification bills per million rows processed. It starts at 75,000 credits per million rows under Flex Credits, which tiers down with volume, and is a flat 100,000 under Data Services, which does not tier.

Salesforce does not publish a statement that identity resolution cannot run against a federated share, so treat this as our recommendation rather than a documented limitation: we land match keys in an ingested stream because that is the configuration the unification documentation describes, and we have not verified the federated case in an org.

Data that drives real-time journeys forces ingest, whatever the score.

Real time in Data 360 means the sub-second layer, and it engages only when the mapped data model object is a member of a real-time data graph.

A federated share cannot serve that. Query federation reads live, but the acceleration cache that keeps it affordable refreshes on a schedule with a floor of 15 minutes, which is not a journey trigger.

It is also the most expensive line on the card. The Real-Time Pipeline starts at 250,000 credits per million combined events, API calls and actions, falling to 50,000 at the top volume tier, so this is a capability to buy deliberately rather than to arrive at by accident.

Federate it: zero-copy

Snowflake, Google BigQuery, Databricks and Amazon Redshift are the four platforms Data 360 can query in place without copying the rows in. S3, Google Cloud Storage and ADLS federate too, but only when the data is in Iceberg format.

Query federation reads live, and the acceleration cache that keeps repeat queries affordable refreshes on a schedule you set anywhere from 15 minutes to 7 days. Relaxed freshness is what makes that cache do its job.

Be careful with the usual argument that a copy costs ingestion credits. On the April 2026 Flex Credits rate card there is no batch ingestion usage type at all, and Salesforce's pricing page says bringing data into Data 360 is free. It is still true on the legacy Data Services regime, where external batch bills 2,000 and streaming 5,000 credits per million rows, so check which regime your contract sits on before you use it.

What federating genuinely avoids is the recurring work on a copy. Profile unification starts at 75,000 credits per million rows on the Flex card and is 100,000 on Data Services, segmentation bills on the records a segment processes, and queries bill per million rows processed. The Flex figure is the base step of a four-step volume tier, so a large estate pays less per row than a small one; there are no volume tiers on Data Services at all.

Know where the query bill lands. Rows-accessed billing on an external data share applies only to cross-cloud and cross-region queries, at 70 credits per million rows, and Data 360 is hosted only on AWS. A same-region Snowflake share on AWS consumes no credits for the query; a BigQuery share is cross-cloud by definition and always does.

Split it: ingest the keys, federate the bulk

In our experience this is the honest answer for most mid-size estates: ingest the narrow set of attributes that drive identity resolution and live segmentation, and leave the wide historical tables federated. It is more design work up front and it is the pattern that survives contact with a real bill.

Both halves have a meter on them. Profile unification starts at 75,000 credits per million rows under Flex Credits and 100,000 under Data Services, and segmentation bills on the records a segment processes, while a federated share bills 70 credits per million rows accessed, and only when the query crosses a cloud or a region.

The split is only worth the design effort while the ingested half stays narrow, because the copy carries the recurring transform and insight cost that the federated half does not.

Ingest it into Data 360

In our experience freshness, query volume and identity requirements point the same way at this usage: a federated share would be slower and more expensive than a copy.

Under Flex Credits the copy itself is close to free. There is no batch ingestion usage type on the April 2026 rate card and the streaming pipeline line explicitly excludes bulk-mode Ingestion API. Under the legacy Data Services regime it is not free: external batch bills 2,000 and streaming 5,000 credits per million rows. The two regimes have run side by side since February 24, 2026, so the ingestion cost of this decision depends entirely on which one you are on.

The recurring cost is what happens after the data lands: unification, which starts at 75,000 credits per million rows on the Flex card and is 100,000 on Data Services, plus segmentation and activation billing on the records they process.

Ingest it. One of your answers decides this on its own.

Match keys are what an identity resolution ruleset runs on, and unification bills per million rows processed. It starts at 75,000 credits per million rows under Flex Credits, which tiers down with volume, and is a flat 100,000 under Data Services, which does not tier.

Salesforce does not publish a statement that identity resolution cannot run against a federated share, so treat this as our recommendation rather than a documented limitation: we land match keys in an ingested stream because that is the configuration the unification documentation describes, and we have not verified the federated case in an org.

Real time in Data 360 means the sub-second layer, and it engages only when the mapped data model object is a member of a real-time data graph.

A federated share cannot serve that. Query federation reads live, but the acceleration cache that keeps it affordable refreshes on a schedule with a floor of 15 minutes, which is not a journey trigger.

It is also the most expensive line on the card. The Real-Time Pipeline starts at 250,000 credits per million combined events, API calls and actions, falling to 50,000 at the top volume tier, so this is a capability to buy deliberately rather than to arrive at by accident.