Your data pipeline costs are high because duplication is still the default
Moving data feels like progress. Pipelines get built, jobs get scheduled, dashboards get populated. Then the bills arrive and the numbers on those dashboards are still two hours old.
Zero Copy is Salesforce’s answer to that pattern. The concept is straightforward: query the data where it lives instead of copying it somewhere else first. The strategic implications for how organisations manage their data estate are considerably less straightforward, and that is what leaders need to understand before committing to a rollout.
What Zero Copy changes for cost and speed
Traditional data integration between a warehouse like Snowflake or BigQuery and a platform like Salesforce has followed the same basic model for years. Extract data from the source, transform it, load it into the destination, keep the sync job running, fix it when it breaks, reconcile the drift when numbers do not match. Every copy is a maintenance obligation.
Zero Copy replaces that model with direct federation. Salesforce Data 360 connects to the external system and sends queries against the data where it already lives. The results come back without a copy of the underlying data ever moving to a new location. When the source data changes, the next query reflects that change immediately.
The cost reduction argument operates on two levels. Storage costs drop because duplicate datasets are eliminated. Engineering costs drop because the sync pipelines, the error handling, the reconciliation processes, and the monitoring overhead that comes with them no longer need to exist. For organisations running multiple integration pipelines into Salesforce, that engineering overhead is more significant than the storage bill.
On speed, the practical outcome depends heavily on where data physically sits relative to where the query runs. Data 360 uses advanced query pushdown, which delegates computation back to the originating warehouse rather than pulling raw data across and processing it in Salesforce. When the data and the compute are in the same cloud region, this is fast. When they are not, the cross-region transfer introduces the latency that Zero Copy was supposed to eliminate.
Use cases that work well
Zero Copy performs well in specific scenarios and those scenarios share common characteristics.
Operational reporting where freshness matters. If a revenue dashboard, a service queue metric, or an account health score needs to reflect what happened in the last fifteen minutes rather than the last sync cycle, federating from the warehouse eliminates the lag. The data is always current because it is never a copy.
Large reference datasets that would be expensive to replicate. Product catalogues, entitlement records, historical transaction data, enrichment datasets from third-party providers. These are large, they change infrequently at the record level, and they are expensive to maintain as copies. Federating them into Data 360 for use in segmentation and identity resolution keeps the warehouse as the source of truth without duplicating the storage cost.
AI and agent workloads requiring real-time context. Agentforce and Einstein features fed by stale copied data produce outputs that reflect the past rather than the present. Zero Copy allows AI features to operate against live warehouse data, which meaningfully changes the quality of the output in time-sensitive interactions such as service escalations or dynamic pricing decisions.
Bidirectional insight sharing. Zero Copy is not only inbound. Data 360 can share unified customer profiles, segmentation outputs, and AI-generated insights back to the warehouse without replication. Teams that need Salesforce-derived insights in their BI tools or data science environments get those outputs written back to Snowflake or BigQuery without another pipeline layer.
Security and access implications
Zero Copy changes the security model in ways that require deliberate attention before deployment.
With traditional ingestion, access control is applied when data arrives in Salesforce. The ingested dataset can be governed independently of the source. With Zero Copy, access control lives at the source. The permissions set in Snowflake, BigQuery, or the relevant warehouse determine what Salesforce can see. If those permissions are broad, the federation inherits that breadth.
The implication for leaders is that permission mapping needs to happen before Zero Copy goes live, not after. Which tables and views is Data 360 authorised to query. Which fields within those tables. Which profiles or roles within Salesforce can access the federated data once it appears in the platform. These questions have answers that sit across two systems, and the governance model needs to account for both.
PII handling deserves specific attention. One of the stated benefits of Zero Copy is that personally identifiable information stays in its original governed environment rather than being duplicated into a new location. That is accurate, but it does not reduce the compliance obligation. If GDPR, HIPAA, or any other regulatory framework applies to the data in the warehouse, federating it into Salesforce does not change what those obligations require. Compliance teams should be part of the Zero Copy governance conversation from the beginning.
Salesforce provides Private Connect for Data 360, which allows federating from warehouse environments locked within a private cloud network. For organisations with strict network isolation requirements, this is the relevant configuration to understand before assuming Zero Copy requires exposing source systems to the public internet.
Implementation checklist and governance
Before a Zero Copy rollout, the following decisions should be made explicitly rather than discovered during deployment.
- Identify the use cases. List the specific reporting, segmentation, or AI scenarios that will use federated data and confirm that Zero Copy fits each one based on the criteria above.
- Audit the source data. Assess data quality, field naming conventions, and data type handling in the warehouse before connecting it to Data 360. Quality problems in the source appear directly in the federation.
- Map permissions before connecting. Define exactly which tables, views, and fields Data 360 is authorised to access. Do not default to broad warehouse permissions because the connection is easier to configure that way.
- Confirm cloud region alignment. Verify that Data 360 infrastructure and the warehouse are in the same cloud region. Cross-region federation should be tested for latency before being used for time-sensitive workloads.
- Assign data owners for federated sources. Each federated data source should have a named owner who is responsible for schema changes, access updates, and communication with the Salesforce team when something in the warehouse changes.
- Define a change communication process. When a warehouse table schema changes, the impact on Data 360 queries and segments needs to be assessed before the change is deployed. Without a communication process, schema changes become incidents.
- Decide what stays ingested. Zero Copy and ingestion are not mutually exclusive. The implementation plan should clearly identify which data should continue to be ingested, which should be federated, and why.
Governance for Zero Copy is not more complex than governance for ingestion. It is differently complex. The skills and processes that already exist for managing ETL pipelines do not transfer directly. Teams need to build familiarity with how changes at the warehouse level affect the Salesforce layer, and that requires both technical understanding and clear ownership across the two environments.
Data strategy improves when duplication stops being the default. Zero Copy makes that possible. Governance is what makes it last.
TrueSolv can assess Zero Copy fit for your Salesforce and data warehouse environment and design the rollout. Follow us on LinkedIn, YouTube for ongoing Salesforce data and CRM operations content.
