Featured
13, Nov 2026
What's an Enterprise Data Warehouse (EDW)? Does Data 360 Replace It?
An EDW stays your system of record. Salesforce Data 360 works alongside it and queries it in place. How do the two work together for enterprise teams?
An EDW stays your system of record. Salesforce Data 360 works alongside it and queries it in place. How do the two work together for enterprise teams?
Last updated: 21 October 2026
An enterprise data warehouse (EDW) is a central system that stores structured data from across a business for reporting and analysis. Salesforce Data 360, formerly Data Cloud, works alongside, accessing data within it. Data 360 queries it in place through zero-copy federation, consolidates the data to enrich the profiles you have for your customers, and activates that profile data across the Salesforce platforms, with the warehouse remaining the system of record and no need for costly ETL mechanisms.
Solution Junkies is a Salesforce consultancy that designs Data 360 architectures for enterprise teams. This article covers what an EDW does, how Data 360 connects to it, where data federation reaches its limits, what the pattern looks like in built environment, high tech, and consumer goods and retail, and where teams go wrong.
An enterprise data warehouse is a central system that stores structured data from across a business. Snowflake, Amazon Redshift, Google BigQuery, and older on-prem platforms all fill this role. The tool varies. The job stays the same.
Data comes in from your source systems. It gets cleaned, reshaped into a consistent format, and loaded into tables designed for analysis. Teams call this process ETL, short for extract, transform, load.
A well-run EDW gives you four things.
If your finance team builds models from this data, or your analysts run quarterly reporting from it, your EDW is doing its job. Nothing about Data 360 changes that.
Salesforce Data 360 is a platform that unifies customer data and puts it to work. Salesforce renamed it from Data Cloud in October 2025, as Salesforce Ben reported. The product underneath stayed the same.
Data 360 connects to external systems through prebuilt connectors, APIs, and zero-copy integrations. Those systems include CRMs, marketing tools, ERPs, websites, applications, cloud storage, and data warehouses such as those suggested above. It standardises that data into a canonical data model, matches records that belong to the same person, and builds a single customer profile. Then it passes that profile to the places where people work: Marketing Cloud, Sales Cloud, Service Cloud, Personalisation tools, and Agentforce.
Here’s how the data moves. Ingested data lands in a Data Lake Object, or DLO. From there it gets mapped into a Data Model Object, or DMO, which gives the data a standard structure. Salesforce documents this in its Data 360 object model guide. Identity resolution then runs across those records. A customer who appears three times across three systems becomes one profile.
Once the profile exists, you can build segments, trigger actions, and send events to the tools that need them.
The timing is the main difference. Your EDW tells you what happened last quarter. Data 360 can tell a service agent, in the middle of a call, that this customer opened a pricing email ten minutes ago and has an open case from last week.
An EDW stores and analyses structured data. Data 360 unifies customer data and activates it. Both hold data about your customers, and they do different work with it.
| Enterprise Data Warehouse | Data 360 | |
| Main job | Store and analyse structured data | Unify and activate customer data |
| Strength | Deep history, batch analytics, BI reporting | Real-time identity resolution, segmentation, consent consolidation, triggered actions |
| Typical users | Analysts, finance, data science | Marketing, sales, service, AI agents |
| Speed | Built for large queries and scheduled loads | Built for the moment a customer interacts |
| Role in the stack | System of record | Activation layer |
A warehouse is excellent at answering big questions across years of data. It was never designed to react to a single customer in the moment. Data 360 does this well. It was never meant to replace a warehouse for heavy analytical work.
So the two don’t compete. They cover different ground.
That matters for three reasons.
You keep one source of truth. The warehouse remains the record, and Data 360 reads from it.
You avoid a second copy to store and sync. Copying a full warehouse into a second platform costs money and creates lag. Queries still carry their own cost, covered below.
You keep your existing governance. Access rules stay where your data team already manages them. Salesforce states that zero copy respects source-level policies such as row-level security and data masking.
The connection also runs in both directions. Data 360 can share enriched data, such as AI-driven insights or joined CRM and warehouse datasets, back into your warehouse.
Your EDW remains your system of record. Data 360 becomes the activation layer on top of it. The two systems add to each other. Neither replaces the other.
If you want to see how this looks in practice, Salesforce publishes reference architectures for Data 360 with Snowflake and Data 360 with Google Cloud, and its zero-copy overview covers the wider approach.
Most enterprise builds use a mix. Salesforce describes three integration patterns: data ingestion, zero-copy federation, and a hybrid of the two. Each fits different data.
| Pattern | What happens | Fits | Watch for |
| Ingestion | Data is copied into Data 360, then transformed and governed there | Data that needs heavy transformation or central governance and auditing | Storage and credit cost, sync lag |
| Zero-copy federation | Data stays in the warehouse and Data 360 queries it when needed | Real-time personalisation, live dashboards, fast onboarding of new sources | Source-side compute cost, query speed |
| Hybrid | Federate some data, cache or ingest the rest | Most enterprise builds | Needs design before the build |
The right mix depends on how fresh each dataset has to be, how often you query it, and what each approach costs on both sides. Salesforce’s interoperability guide tells architects to weigh the cost of onboarding, storing, and transforming data against the cost of querying it directly.
Decide this dataset by dataset. A single pattern for the whole build usually costs more than it should.
Zero-copy data federation saves you a second copy of the data. It still carries cost and performance trade-offs, and Salesforce’s own guidance lists them.
Cost lands on both sides. A federated query uses Data 360 credits and also runs on your warehouse’s compute.
Salesforce’s team advises building a cost model that covers both before you choose a pattern.
Speed follows the source. Query performance depends on the throughput of the external system. Joins between data stored in Data 360 and federated data can also slow queries down.
Caching closes the gap. Salesforce offers cached acceleration, which keeps a periodically refreshed copy of external data. It suits large datasets and frequent queries where slightly stale results are acceptable.
Federate what you need live. Cache or ingest what you query constantly.
One nonprofit we worked with already had an enterprise data warehouse and a CRM. Both worked. Neither could handle complex identity resolution, segmentation, or real-time marketing journeys.
They didn’t need a new warehouse. They needed something that could act on the data they already held.
We synced the existing warehouse into Data 360. The warehouse stayed the central repository. Inside Data 360, we remapped the warehouse fields to standard data models and ran identity resolution to match supporter records. Then we activated the unified supporter profiles across Marketing Cloud and Salesforce CRM.
The warehouse kept its role the whole way through. Data 360 gave the team a way to use what the warehouse already knew.
That pattern repeats across the work we do. The warehouse has years of clean, governed data. What it lacks is a route into the tools where marketers, sales reps, and service teams make decisions. Data 360 supplies that route.
The pattern is the same everywhere. The data behind it changes. Here are three common examples.
A property owner runs a large portfolio of commercial and retail sites. Leasing, building management, finance, and tenant data sit in an EDW on Snowflake. Footfall and Wi-Fi data comes from separate sensor platforms. The CRM holds tenant and prospect contacts but knows nothing about how a site performs.
The warehouse stays the record for leasing and finance. Data 360 federates that data, ingests the sensor and web feeds, and resolves visitors and contacts into unified profiles. Leasing sees site performance on the tenant record. Marketing builds segments by site and audience. Nobody rebuilds the warehouse.
A technology company sells subscriptions across several product lines. Usage telemetry, billing, and entitlement data sit in BigQuery. Account executives work in Sales Cloud, and they often learn an account’s usage has dropped when the customer mentions it.
The warehouse stays the system of record. Data 360 federates only the fields the account team needs, such as active seats, feature adoption, and recent support volume. Those signals appear inside Sales Cloud and feed Agentforce, so a rep walks into a renewal conversation already knowing the account’s health. The raw telemetry stays where it is.
A retailer sells through stores, ecommerce, and marketplaces across several regions. Point of sale, loyalty, returns, and ecommerce data land in an EDW on Redshift. Marketing, service, and the loyalty team each hold a slightly different version of the same customer.
Data 360 federates the warehouse data and resolves identity across channels. A shopper who buys in store, orders online, and contacts service becomes one profile. Consent is applied once and respected everywhere, so a customer who opts out of email is suppressed in every tool and region at the same moment. The warehouse keeps running regional sales analysis and inventory reporting.
Small teams can get away with loose architecture. Enterprises can’t.
Large organisations tend to run several warehouses, sometimes one per region or business unit. Different brands may need to keep their data separate. Legal and security teams want clear answers on who can see what. Cost grows with every ingested record and every federated query.
Data federation suits that environment. You don’t consolidate everything into one new platform. You connect the systems you already trust and leave each in place. Data 360 also supports data spaces, which let you separate data by brand, region, or business unit inside the platform.
Three things matter more as you scale.
Route Data 360 through your EDW when the warehouse is already the trusted home for the data you need. Most mature organisations have a warehouse with years of curated data in it. A few questions will help you decide.
Is your warehouse already the trusted source for customer data? If finance and analytics rely on it, keep it as the record and connect Data 360 to it.
Does the data you need already sit in the warehouse in usable form? Purchase history, product usage, and billing records often do. Federate those instead of rebuilding the pipelines.
Do you need that data in real time inside Salesforce? This is where Data 360 earns its place. Segmentation, triggers, and agent context all depend on speed.
Does your data team own governance for the warehouse? If so, keep access control there and extend it into Data 360 on purpose.
If you answer yes to most of these, the pattern is straightforward. Leave the warehouse alone and build the activation layer above it.
If you don’t have a warehouse, the picture changes. Data 360 can ingest directly from your operational systems, and you can decide later whether a warehouse is worth adding.
You control Data 360 credit costs by deciding what to ingest before anything moves. Data 360 runs on consumption-based credits, so the way you design ingestion decides how many credits you use.
Pulling full raw tables into Data 360 is the most common way teams overspend. It also defeats the purpose of connecting to a warehouse in the first place.
Our consumption blueprints point to a better approach. Ingest only the fields a specific use case needs. Run loads on a batch cadence unless a use case truly requires streaming. Shape the data upstream, in the warehouse, before it moves. Following that approach, our blueprints show annual credit use falling from 2,500,000 to 500,000. That is five times less.
On the data federation side, cost sits in two places. Queries use Data 360 credits and warehouse compute. Model both, and cache the tables you query often.
Copying data back into the CRM adds another layer of cost. You pay for storage, you add sync lag, and you create a second version of the truth that someone has to reconcile.
Decide the use cases first. Then decide which fields they need, and whether each one is federated, cached, or ingested. Cost follows from those choices.
Teams make the same seven mistakes again and again.
Trying to replace the warehouse. Some teams assume Data 360 should take over analytics. Heavy historical reporting belongs in the EDW. Move it and you waste both systems.
Assuming the warehouse makes Data 360 redundant. A warehouse doesn’t resolve identity in real time, manage consent across channels, or trigger a journey at the right second. Data 360 does those jobs.
Copying instead of federating. Duplicating warehouse data into Data 360 raises cost and creates two versions of the truth.
Ingesting everything. Full raw tables burn credits fast. Bring in what the use case needs.
Skipping identity resolution planning. Matching records across systems takes careful rule design. Default settings rarely fit real customer data.
Starting with the tool. The strongest projects begin with a business outcome, like faster case resolution or better segmentation. They build the architecture around that outcome.
Treating zero-copy as free. Federated queries run on your warehouse as well. Model cost on both sides.
An enterprise data warehouse holds your history and supports deep analysis. Salesforce Data 360 turns the customer data inside it into action while the moment still matters. Your EDW stays the system of record. Data 360 becomes the activation layer on top.
Getting the connection right takes planning. Data federation, field selection, identity resolution, and governance all need decisions before the build starts. Those decisions control your cost, your speed to value, and how well the finished system works.
If you run an enterprise in built environment, high tech, or consumer goods and retail, and you’re working out how Data 360 fits with the warehouse you already have, book an architecture review with Solution Junkies. We’ll map the design with you, including governance and cost guardrails, before you commit to a build.
EDW stands for enterprise data warehouse. It’s a central system that stores structured data from across a company for reporting and analysis.
No. Data 360 is a customer data platform. It unifies customer data and activates it across Salesforce. A warehouse is built for storage and analytics.
No. Your EDW stays your system of record. Data 360 sits alongside as the activation layer, and it queries the warehouse without copying the data.
No. Data 360 can ingest from your operational systems directly. If you already have a warehouse, connecting it is usually the stronger route.
Ingestion creates a copy of your data into Data 360, and changes in the source system are not immediately reflected in Data360 until they are pushed. Zero-copy data federation leaves the data in the source and queries it when needed. Many enterprise builds use a hybrid of the two.
Yes. Zero-copy data shares allow you to move data in both directions, so Data 360 can project enriched data, such as insights and joined datasets, back to your warehouse.
No. A federated query uses Data 360 credits and also uses compute on the source system. Salesforce advises modelling cost on both sides before you choose between data federation, ingestion, or a hybrid.
Zero-copy data federation lets one system query data in another without making a duplicate. Data 360 reads from your warehouse in place.
Yes. Data 360 features a robust library of connectors for a wide range of enterprise data platforms (EDPs) and line-of-business systems. For platforms like Snowflake, BigQuery, and Redshift, it supports zero-copy data federation, allowing you to query data directly where it lives.
Note on capabilities: Connector features vary by system. While many platforms connect seamlessly, support for zero-copy ingestion versus zero-copy data shares depends on the specific source system's architecture and limitations.
