They are not three products competing for the same budget line, which is how they get pitched. A data warehouse answers questions you already know how to ask. A data lake keeps what you cannot model yet, cheaply. A CDP resolves scattered identifiers into one customer and pushes that profile into a tool that acts on it. Most teams asking “CDP vs data lake” already own a lake and are being sold a CDP, and the honest answer in that conversation is often that they need neither — they need someone to finish the identity work they already started.
| Data Warehouse | Data Lake | CDP | |
|---|---|---|---|
| Primary job | Answer known questions fast | Keep everything until you know what it is for | Resolve identity, then act on it |
| Data shape | Modelled on write — schema decided up front | Raw, schema applied on read | Modelled around a person |
| Who uses it | Analysts, BI tools | Data engineers, data scientists | Marketing and CX teams, self-serve |
| Latency | Batch, hours to a day | Batch, whenever a job runs | Near real-time by design |
| Output | Dashboards and reports | Datasets and models | Audiences pushed into channels |
| Cost driver | Storage plus query compute | Storage, cheapest per TB | Profiles and events, not bytes |
What a Data Warehouse Is For
A warehouse is where you put data once you have decided what it means. Snowflake, BigQuery, Redshift, Synapse — the schema is agreed before the data lands, which is exactly why queries are fast and exactly why adding a new source takes three weeks. That trade is the whole product. You are paying modelling effort up front to buy query speed and trustworthy numbers later.
The failure mode is well known: the warehouse becomes correct and slow to change, so teams that need an answer this week route around it, and within two years you have a warehouse plus four shadow spreadsheets that disagree with it. If that sounds like your org, buying a CDP will not fix it. You have a governance problem wearing a tooling problem's clothes.
What a Data Lake Is For
A lake exists because the modelling decision is the expensive part, and sometimes you genuinely do not know yet. Clickstream, application logs, device telemetry, five years of raw event data — you keep it in object storage in whatever shape it arrived, apply schema when you read it, and defer the decision. Storage is priced like commodity object storage, so deferring costs almost nothing.
The honest version of the downside: a lake with no catalogue, no ownership, and no quality contract is a swamp, and the industry named it that for a reason. Table formats like Delta Lake and Iceberg exist to claw back the warehouse guarantees people missed — which is why most real architectures now sit somewhere in the middle and get called a lakehouse.
What a CDP Does That Neither of Them Does
Two things, and it is worth being precise, because everything else a CDP offers you can get elsewhere:
- Identity resolution. The anonymous session on Tuesday, the email address that converted on Friday, the loyalty number at the till, and the support ticket last month are one person. Deciding they are one person, with confidence rules and survivorship logic when the fields conflict, is the hard part — and it is the part teams underestimate when they say they will build it on the lake.
- Activation. Pushing that resolved profile into the tool that actually sends the message, inside a window where it still matters. A segment that lands in the email platform 24 hours later is a different product from one that lands in 90 seconds, whatever the architecture diagram says.
Storage is not the differentiator. If a vendor is selling you a CDP on the basis that it holds all your customer data, they are selling you a warehouse with worse economics. Ask about identity resolution and activation latency instead.
“We Already Have a Warehouse. Do We Need a CDP?”
This is the actual question behind most CDP evaluations, so here is the test we use. If your warehouse already holds unified customer records, and your marketing tools can either query it directly or receive a reverse-ETL sync from it, you have most of a CDP. What you are missing is usually not capability — it is latency and ownership.
Warehouses are batch and belong to a data team with a ticket queue. CDPs are near-real-time and are built so a marketer can define an audience without filing a ticket. Buy the CDP when the bottleneck is that marketing cannot act without engineering, not when the bottleneck is that the data does not exist. If the data does not exist, a CDP will resolve identities across the sources you have not connected yet, which is to say it will resolve nothing.
What Each One Costs
We are not quoting list prices here because every vendor in this space re-packages annually and any number would be stale before you read it. The shape of the pricing is stable, though, and the shape is what decides the answer.
Lakes and warehouses charge for bytes stored and compute consumed. CDPs charge for profiles and events, so the bill tracks your customer base and how active they are, not how much data you keep. That has a counter-intuitive consequence: a business with modest data volume and a very large, very active customer base can pay more for a CDP than for the warehouse holding the same information, and a business hoarding years of clickstream for a handful of enterprise accounts sees the opposite.
The comparison people skip is the build cost. “We will do identity resolution on the lake” is a real option and sometimes the right one, but price it as ongoing engineering headcount rather than a one-off project. Identity rules drift as you add channels, and the maintenance never ends.
Where Data Clean Rooms Fit
A clean room is a different job again, and it turns up in these evaluations because vendors have started bundling it. A CDP unifies data you own. A clean room lets two parties analyse their data together without either seeing the other's raw records — a retailer and a brand measuring how much their customer bases overlap, without exchanging customer lists.
If your problem is “who is this customer and what should we send them,” that is a CDP. If it is “what do our two customer bases have in common, and neither legal team will allow a file transfer,” that is a clean room. Buying one does not give you the other, whatever the bundle says.
Where Salesforce Data 360 Sits
Data 360 — renamed from Salesforce Data Cloud — is deliberately both. There is a lakehouse underneath it, and it supports zero-copy federation to Snowflake, BigQuery and Databricks, so you can leave data where it already lives instead of paying to move and duplicate it. On top of that it runs identity resolution and activates resolved profiles into Marketing Cloud, Sales Cloud, Service Cloud and Agentforce.
That is why the CDP-or-lake framing misfires on it, and the buying question is simpler than the category question: how much of your customer data already sits in Salesforce, and how much of your activation happens in Salesforce channels? The more both are true, the better the economics look and the less integration work you are signing up for. If the answer to both is “not much,” a neutral CDP or a reverse-ETL layer on the warehouse you already run will usually cost less and fit better — and we would rather say that now than eight weeks into a project.
We go deeper on that specific decision in Is Salesforce Data Cloud a CDP?, including how it compares to Adobe Real-Time CDP and Segment.
When You Should Not Buy Any of Them
Three situations where the answer is to stop and fix something else first:
- You have fewer than a handful of customer data sources and they already share a key. If everything joins on a clean customer ID today, you do not have an identity problem, and a CDP solves a problem you do not have. Reverse-ETL from what you already run.
- Nobody owns customer data definitions. If two teams cannot agree what an active customer is, adding a system that resolves identities will produce a fast, confident, wrong answer. Fix the definition first — it costs meetings, not licences.
- The real complaint is campaign execution speed. Sometimes the segment takes three weeks because the approval chain takes three weeks. No architecture change touches that, and it is worth checking before a procurement cycle starts.
The Short Version
Warehouse for questions you know how to ask. Lake for data you are not ready to model. CDP when identity resolution and activation latency are the bottleneck, and only once you can name which one. Most architectures that work end up with two of the three, and the second one gets bought a year later than the vendor wanted and a year earlier than the finance team did.
Not sure which of the three you actually need?
Tell us where your customer data lives now and what you are trying to activate. We will tell you which layer is your bottleneck — including when the answer is that you already own it and nobody has finished wiring it up.
Four fields, no call required. We reply within one business day.
Frequently asked questions
What is the difference between a CDP and a data lake?
A data lake stores raw data in whatever shape it arrived in, cheaply, so you do not have to decide what it is for before you keep it. A CDP does something a lake does not: it resolves identity, stitching the anonymous web session, the email address, the loyalty number, and the support ticket into one person, then pushes that resolved profile into tools that act on it. A lake is storage plus optional compute. A CDP is identity resolution plus activation. You can build identity resolution on a lake, and plenty of teams have, but you are then maintaining the thing you would have bought.
Do I need a CDP if I already have a data warehouse?
Often not. If your warehouse already holds unified customer records and your marketing tools can query it or receive a reverse-ETL sync, you have most of a CDP already. The gap is usually latency and ownership, not capability: warehouses are batch-oriented and owned by a data team with a ticket queue, while CDPs are near-real-time and designed for a marketer to self-serve. Buy a CDP when the bottleneck is that marketing cannot act without engineering, not when the bottleneck is that the data does not exist.
Is a CDP more expensive than a data lake?
Per unit of data, yes, by a wide margin. Lake storage is priced like commodity object storage and you pay for compute only when you query. CDPs are priced on profiles and events, so cost scales with your customer base and their activity rather than with bytes. The crossover is about what you do with it: if you are storing five years of clickstream to analyse later, a lake is dramatically cheaper. If you are activating a million profiles daily across six channels, building that on a lake costs more in engineering time than the CDP licence. Model both against your actual profile count before assuming the lake is cheaper.
Is Salesforce Data 360 a CDP or a data lake?
Both, deliberately. Data 360 (renamed from Salesforce Data Cloud) has a lakehouse underneath, so it stores raw data at scale and supports zero-copy federation to Snowflake, BigQuery and Databricks rather than forcing you to move it. On top of that it runs identity resolution and pushes resolved profiles into Marketing Cloud, Sales Cloud, Service Cloud and Agentforce. That combination is why the CDP-or-lake question misfires on it. The buying question is simpler: how much of your customer data already sits in Salesforce? The more it does, the better the economics.
What is the difference between a CDP and a data clean room?
A CDP unifies data you own. A clean room lets two parties analyse their data together without either seeing the other's raw records — a retailer and a brand measuring campaign overlap, for example. They answer different questions: a CDP asks who is this customer and what should we send them, a clean room asks what do our two customer bases have in common without exposing either. Some CDPs, Data 360 included, now ship clean room features, but the underlying jobs are separate and buying one does not give you the other.