Imagine a company with 500 million billing history rows sitting in Snowflake.
- The Old Way: Data engineers build a complex pipeline to ingest all 500 million rows into Salesforce. The company pays to store the massive dataset twice. They then spend months babysitting the pipeline to ensure both copies stay perfectly in sync. Meanwhile, the data warehouse team views Salesforce as a competitor duplicating their hard work.
- The Zero-Copy Way: You simply point Salesforce Data Cloud at the existing Snowflake table. The data is queried in place and dynamically joined to the unified customer profile only when needed.
- The Payoff: The brittle pipeline is deleted, the duplicate storage bill vanishes, and the data warehouse team becomes a partner. You moved the question, not the data.
The Concept: Lakehouse Architecture & Federation
Salesforce Data Cloud is built on a Lakehouse architecture. This simply means it combines the best of two older ideas:
- Data Lake: Designed to hold enormous volumes of raw, unstructured data cheaply (but can be slow and messy to query).
- Data Warehouse: Designed to hold clean, highly structured data that queries lightning-fast (but is expensive and strict).
A lakehouse gives you both capabilities in one place, eliminating the need to constantly shuffle data between systems. The crown jewel of this architecture is Zero-Copy Federation. Data Cloud can query external databases like Snowflake, Databricks, BigQuery, or Redshift natively. It also works in reverse—those platforms can query Data Cloud without exporting the data.
The Benefits:
- No pipelines to build, monitor, or fix.
- No duplicate storage costs.
- No data drift (the data is never stale because there is no "second copy").
- Massive cost savings. A federated query is vastly cheaper in compute credits compared to running a heavy batch ingestion pipeline for millions of rows.
The Trade-Off:
Because a federated query must travel across the network to a remote system, it is inherently slower than querying data stored locally in Data Cloud. Furthermore, if Snowflake goes offline, your federated data becomes unavailable.
- Rule: Move the question, not the data. Federate the big and cold; ingest the small and hot.
- Gain: You can access hundreds of millions of external rows with zero pipelines to maintain and zero duplicate storage fees.
- Reach For: Use federation when data is massive, historical, and already sitting in a supported external data warehouse.
- Price: Network latency. Because the query crosses vendor networks, it is slower than accessing local data.
- Limits: You are completely dependent on the external platform's uptime and query execution speed.
- Mirror — Ingestion: Copying data directly into Salesforce gives you local speed and total independence, but saddles you with pipeline maintenance, double storage bills, and data reconciliation headaches.
- At Volume: The larger and colder the dataset, the stronger the architectural case for Zero-Copy. Small, highly active data is the wrong candidate.
Core Q&A: Architectural Decisions
A: Copying 500 million rows means signing up for unnecessary storage costs and a fragile synchronization pipeline. Instead, register the Snowflake table in Data Cloud via Zero-Copy Federation. It will appear in your data model like any native object, available for segmentation and AI agents.
The architectural secret is splitting the data based on its velocity and usage:
- Federate the heavy history: Massive, slowly changing datasets (like 5 years of invoices) do not need to be accessed in 10 milliseconds. Leave them in Snowflake.
- Ingest the hot triggers: If a specific field (like
Current_Account_Status) drives a real-time web personalization segment, ingest it. You cannot afford the network latency of a federated query for a real-time user experience.
Always state the risk out loud: "If Snowflake has an outage, our federated data is offline. Therefore, anything mission-critical to real-time operations must be ingested or cached." Nailing that split is the entire design decision.
Scenario-Based Follow-Ups
Do not treat Zero-Copy as a magic bullet for every integration. It is the wrong architectural choice in three specific scenarios:
- You need real-time speed: Federated queries cross external networks. Real-time website personalization or immediate point-of-sale triggers cannot wait for that round trip.
- You require high availability: Federation tethers you to the external system's uptime. If your customer service agents rely on federated data and the data warehouse team takes Snowflake down for patching, you take the outage.
- Heavy, repeated transformations: If you are repeatedly querying and transforming the exact same millions of rows every day, the ongoing external compute and network costs will skyrocket. In that case, ingesting it once locally becomes far cheaper.
A: Historically, you had to move data from a messy, cheap Data Lake into a highly structured, expensive Data Warehouse just to make it usable. This forced teams to build brittle ETL (Extract, Transform, Load) pipelines.
Because Salesforce Data Cloud is built natively as a Lakehouse, it natively understands both structured records (like CRM data) and unstructured files (like PDF documents or raw event logs) in the same storage layer. This unified engine is exactly what gives it the power to reach out to external warehouses and interpret their data on the fly without requiring a rigid ETL pipeline first.