All insights

Data 360

Salesforce Data 360 zero copy: what moves and what it costs

Compare live query federation, file federation, and acceleration in Data 360. Understand copies, freshness, rows-accessed billing, and a practical cost test.

A warehouse table can be available in Data 360 without a scheduled import. That doesn’t make every downstream result current, every operation free, or every derived dataset absent from Salesforce.

Data 360 can query supported external sources through federation. Choose the connection method per workload, then measure source freshness, rows accessed, and both platforms’ costs. “Zero copy” describes how data is accessed; it doesn’t settle the whole architecture decision.

If your question is whether Salesforce can query warehouse data without copying the source table into Data 360, the answer is yes. If your requirement is that no customer-derived information ever leaves the warehouse, evaluate the complete processing path before approving the design.

Separate query federation, file federation, and acceleration

Salesforce’s zero-copy overview distinguishes two federation paths. Query federation asks the external system’s query engine to execute work. File federation uses Data 360 compute to read supported external storage. Connector and table-format support determine which is available.

Acceleration introduces another choice. With acceleration enabled, Salesforce caches external records in a data lake object. Refresh settings govern when that cached data changes. A connector can therefore belong to the zero-copy product family while a particular accelerated stream maintains a copy.

WorkloadMethod to test firstMain question to resolve
Occasional queries against a governed warehouse tableQuery federationWhat compute and rows-accessed charges does each query produce?
Large tables exposed through a supported file connectorFile federationAre the catalog, permissions, format, and region supported?
Repeated access to the same data with an acceptable refresh delayAcceleration or ingestionDoes a maintained copy improve total cost and response time?
External changes that must trigger an actionA supported change-detection pathCan the chosen connector detect changes with the required delay?
Warehouse analysts needing Data 360 outputsOutbound data sharingWhich objects and users should be able to access the share?

This is a starting point for testing. A large table doesn’t automatically make one method cheaper, and an infrequent query can still be expensive if it scans broadly.

File federation can avoid executing the query on the external warehouse’s compute engine. That is narrower than saying the external provider has no charges. Include applicable storage, requests, catalog services, and network transfer in the estimate for your configuration.

Salesforce’s file federation introduction explains the Iceberg-based approach and support for change-detection features without a cache. Check current connector documentation for availability and restrictions; a historical beta announcement is not an entitlement check for your org.

Freshness depends on the whole path

Live access can return the latest committed data exposed by the source. It cannot make an upstream warehouse load finish sooner. Nor does a live source query prove that a previously generated segment, identity result, or activation has refreshed.

For a customer-service use case, write down four separate times: when the business event occurred, when it reached the source table, when Salesforce processed it, and when the user-facing action consumed it. The oldest dependency determines how useful the final answer is.

Suppose a payment posts at 10:00 but the warehouse loads it at 10:30. Querying the warehouse at 10:05 still returns the earlier state. Federation removes one possible synchronization step; it doesn’t remove the source pipeline’s delay.

Test with an identifiable synthetic record and timestamps. Change a source value, query it, then inspect the downstream output your business uses. Report those measured delays separately. Calling the whole route “real time” hides which step needs work.

For event-driven use cases, query access and change detection are different capabilities. Trailhead describes caching requirements for trigger-based features on query federation and change-detection support for file federation. Validate the specific connector and feature combination rather than inferring event delivery from a successful query.

A small result set can still produce a large bill

Salesforce’s federation billing explanation defines non-accelerated consumption in terms of rows accessed, including rows scanned or touched. Count the work required to obtain the result, including records read before filtering.

An output of 40,000 customers doesn’t reveal whether the source accessed 50,000 rows or 100 million. Filtering and source optimization can change the work. Measure actual usage for a representative query before multiplying by daily segment, preview, and activation frequency.

A useful comparison separates the two routes:

Live federation credits
  = total measured rows accessed / 1,000,000
    × applicable federation credit multiplier

Acceleration ingestion credits
  = total rows processed across initial and subsequent refreshes / 1,000,000
    × applicable ingestion credit multiplier

Those expressions compare two consumption lines, not total cost. Add external compute, any network charges, storage, and other Data 360 processing used by the workload. Segmentation, for example, still consumes resources when its input comes from a cached object.

For illustration, Salesforce’s December 2025 implementation article used 70 credits per million rows for live access and 2,000 for cached ingestion. These are historical example multipliers; use the rate card and terms applicable to your current contract.

At those multipliers, 30 full scans of 100 million rows produce 210,000 federation credits. One ingestion of 100 million rows produces 200,000 ingestion credits. That arithmetic is a hypothetical comparison, not a benchmark or proof that caching wins after a month.

The result changes if queries touch fewer rows, the cache needs repeated full refreshes, or additional processing dominates the bill. Incremental refreshes also require a reliable change field and a tested handling path for updates and deletions. Compare both routes over the same period and workload.

Our Data 360 credit optimization guide covers the broader consumption review. Keep that review separate from a connector’s successful setup test.

Account for derived data and outbound sharing

A zero-copy connection doesn’t eliminate the data created by subsequent processing. For example, Salesforce’s search-index documentation describes chunking content and generating embeddings. An indexing pipeline is a separate storage and retention decision from the source connection.

Map each output that your design creates: cached records, unified profiles, calculated results, search representations, and exported or activated records. Record its location, access policy, retention, and deletion behavior. Don’t infer those properties from the label on the source connector.

That map also helps with incident analysis. If an identity rule joined the wrong people, a corrected source query doesn’t establish that every resulting action has been repaired. Trace the affected outputs and actions using the identity-resolution impact guide.

Outbound sharing runs in the other direction. Salesforce’s Snowflake sharing walkthrough describes exposing Data 360 data through a configured share and share target. Review this route separately from inbound federation, including permissions and consumption.

Use the connector-specific guides for Snowflake and Databricks when deciding how to implement the connection. A general architecture comparison cannot establish that two providers have identical behavior.

Run one workload before expanding the connection

Choose one business output, such as a daily renewal audience. Record its required freshness, response time, expected query frequency, and permitted data locations. Use the same source records and filters when comparing federation with acceleration.

Capture a normal run, a repeat run, and a source change. Then test an expired credential, a denied permission, and a delayed source update. The result should show what the user sees and which owner receives the failure, not simply whether the connector remains green.

A practical acceptance record includes query duration, measured consumption, source timestamps, output timestamps, and reconciliation counts. No production benchmark is claimed here; this is a test method to run against your own workload.

Understanding the basics

Does Data 360 query warehouse data without copying it?

Yes, supported federation paths can access the source without a persistent import of the source table. Acceleration changes that by caching records. Downstream indexing, unification, and activation also need their own data-placement review.

Does zero copy mean there are no integration costs?

No. Include Data 360 consumption and any costs from the external platform and network. File federation avoids external query-engine execution, but that doesn’t establish that every external service is free.

When should I use ingestion or acceleration instead?

Test a maintained copy when repeated access, response-time requirements, or feature compatibility make it useful. Compare the full refresh cycle and processing costs against measured federation usage. The correct choice can differ between two tables in the same warehouse.

Keep the first deployment small enough that you can explain every row of the bill and every delay in the output. Expand after those measurements meet the business requirement.

Keep reading

All insights