Quick answer: A composable CDP assembles customer data platform capabilities (identity resolution, audience building, activation) on top of your existing cloud data warehouse instead of copying data into a vendor's store. A packaged CDP is a single vendor product with its own database. Choose composable if your warehouse already holds unified customer data and you have data engineering capacity; choose packaged if you need marketer-operated speed and do not. Many enterprises run a hybrid.
Few decisions in the customer technology stack have been reframed as fast as the customer data platform. Five years ago the question was which CDP to buy. Today, with most large enterprises running a cloud data warehouse that already holds transactions, product events and service history, the question is whether to buy a CDP at all, and if so, whether it should own the data or simply read it.
This matters now because everything else on the 2027 roadmap depends on the answer. Journey orchestration, personalization, measurement and AI agents all need a trusted, governed view of the customer. Where that view lives determines cost, speed, privacy exposure and how much engineering capacity marketing will need to borrow.
This guide is for the CMO, CDO and CIO who have to make or ratify that call. It defines the three options, sets out a decision framework, and names the questions that usually settle the debate in the room.
What is a composable CDP, and how is it different from a packaged CDP?
The CDP Institute, which coined the category, defines a customer data platform as packaged software that creates a persistent, unified customer database accessible to other systems. The defining idea was a separate, marketer-controlled store of customer data.
A composable CDP keeps the capabilities but drops the separate store. Identity resolution, segmentation, audience building and activation run directly against the data warehouse or lakehouse (Snowflake, BigQuery, Databricks, Redshift and the like), typically through a reverse-ETL or warehouse-native activation layer, with event collection and consent handled by separate components. The data stays in one governed place; the CDP becomes a set of functions over it.
A packaged CDP is a single product that ingests data from your sources into its own database, resolves identities there, and exposes segmentation and activation to marketers. It is faster to stand up when the warehouse is immature and it gives marketing an environment it controls.
The data warehouse alone is the third option: use the warehouse as the customer data store, build audiences in SQL or a semantic layer, and push to channels through native connectors or reverse ETL without labeling any of it a CDP.
- Where customer data lives — Composable CDP: Your warehouse · Packaged CDP: Vendor's database (copy) · Warehouse only: Your warehouse
- Identity resolution — Composable CDP: Warehouse-native or add-on · Packaged CDP: Built in · Warehouse only: Built by your team
- Time to first use case — Composable CDP: Weeks if warehouse is ready · Packaged CDP: Typically 3-6 months plus integration · Warehouse only: Weeks to months depending on skills
- Who operates it day to day — Composable CDP: Marketing ops with data engineering support · Packaged CDP: Marketing ops · Warehouse only: Data/analytics engineering
- Real-time capability — Composable CDP: Depends on streaming into warehouse · Packaged CDP: Often strong for event-triggered use cases · Warehouse only: Usually batch unless engineered
- Governance and privacy — Composable CDP: Single copy, warehouse controls apply · Packaged CDP: Second copy of PII to govern · Warehouse only: Single copy
- Cost model — Composable CDP: Warehouse compute plus activation tooling · Packaged CDP: License tied to profiles or events · Warehouse only: Compute plus internal labor
- Vendor lock-in — Composable CDP: Low to moderate · Packaged CDP: Moderate to high · Warehouse only: Low
Is a data warehouse a CDP?
Not by itself. A warehouse stores and queries data; it does not, out of the box, resolve identities across devices and systems, maintain consent state per channel, or let a marketer build and ship an audience without writing SQL. Those are the capabilities a CDP adds.
The reason the distinction has blurred is that warehouse vendors and the activation ecosystem around them now supply most of those pieces. If your data team has already built an identity graph and a governed customer 360 table, the gap between "warehouse" and "composable CDP" is a marketer-facing audience tool and some activation connectors. If they have not, the gap is a multi-quarter engineering program, which is exactly what a packaged CDP is selling you a shortcut around.
Do we still need a CDP if we have a data warehouse?
Work through four questions. Each has a clear implication.
1. Is the warehouse the system of record for customer data today? If transactions, product events, service interactions and consent all land there with acceptable latency, the warehouse is your customer data layer and a composable approach is the natural fit. If marketing data lives in a dozen SaaS tools that never reach the warehouse, a packaged CDP may be the pragmatic way to unify it, or the audit may show the real fix is the data pipeline, not a new platform.
2. Who will operate audiences and journeys? Composable architectures assume data engineering stays in the loop. If your data team is already a bottleneck, giving marketing a packaged environment they can run alone may be worth the duplication. Be honest about this; it is the most common reason composable projects stall.
3. What latency do your highest-value use cases actually need? Cart abandonment, fraud alerts and in-session personalization need seconds. Lifecycle marketing, loyalty, win-back and most B2B journeys are fine with hourly or daily refreshes. Enterprises frequently over-buy real-time capability for use cases that run on a nightly batch.
4. How many copies of customer data can you defend? Under GDPR, UK GDPR, CCPA/CPRA and the Australian Privacy Act, every additional store of personal data is another place to honor access, deletion and consent requests. A second copy inside a packaged CDP is manageable, but it must be in scope for your privacy program from day one. Composable architectures win on this dimension by default.
In practice: A multi-brand consumer goods company had a mature Snowflake environment, a two-year-old identity graph built by its data team, and a packaged CDP bought by one brand that held a partial copy of the same customers. The audit found that the CDP's audiences were rebuilt nightly from the warehouse anyway. The company retired the packaged CDP at renewal, added a warehouse-native audience and activation layer that marketers could operate, and kept a lightweight event streaming service for the handful of real-time triggers. Time to launch a new audience dropped from weeks to days, and the privacy team removed one system from its deletion workflow. The decisive factor was not cost; it was that the warehouse was already the truth.
What is the difference between a CDP and a CRM?
A CRM is a system of engagement for known contacts, built around records that sales, service and marketing users edit by hand or through workflows. A CDP (packaged or composable) is a system of insight built around behavioral and transactional data from every source, including anonymous and pre-login activity, resolved into unified profiles that other systems consume.
In practice the CRM is one of the CDP's most important sources and one of its most important destinations. The confusion in 2026-2027 comes from CRM vendors shipping their own data clouds and calling them CDPs. Those products can be excellent, but evaluate them against the same framework: where does the data live, who operates it, and how many copies are you creating?
What are the main CDP use cases, and which architecture suits each?
- Suppression and frequency control across paid media — Typical latency need: Daily · Composable fit: Strong · Packaged fit: Strong
- Lifecycle and retention journeys — Typical latency need: Hourly to daily · Composable fit: Strong · Packaged fit: Strong
- Lookalike and value-based audiences for advertising — Typical latency need: Daily · Composable fit: Strong (full warehouse data) · Packaged fit: Moderate (limited to ingested data)
- In-session web and app personalization — Typical latency need: Seconds · Composable fit: Needs streaming layer · Packaged fit: Strong
- Cart or form abandonment triggers — Typical latency need: Minutes · Composable fit: Moderate · Packaged fit: Strong
- Service-to-marketing handoffs (e.g. complaint suppression) — Typical latency need: Hours · Composable fit: Strong · Packaged fit: Strong
- Feeding AI agents a customer context — Typical latency need: Seconds to minutes · Composable fit: Strong if warehouse is current · Packaged fit: Strong
- Measurement and incrementality analysis — Typical latency need: Daily · Composable fit: Strong (same data as finance) · Packaged fit: Weak (partial copy)
The pattern is consistent: the composable approach wins wherever the use case benefits from the full breadth of enterprise data (advertising audiences, measurement, AI context), while the packaged approach has historically been stronger on sub-minute, event-triggered experiences. That gap is narrowing as warehouses add streaming ingestion, but it still exists and should be priced into the decision. For how these use cases are expressed once the data layer is chosen, see customer journey orchestration.
How do you choose between a composable and a packaged CDP?
Run the decision as a short, structured program rather than an RFP.
- Audit the stack first. A martech stack audit will usually reveal whether you already own CDP-like capabilities in three places. Many enterprises discover they have a CDP inside their CRM, another inside their marketing cloud, and the raw material for a third in the warehouse.
- Rank the top ten use cases by value and latency. If eight of ten run on daily data and the warehouse is mature, composable is the default. If the top three are real-time and the warehouse is a reporting store, packaged is the default.
- Score operating capacity. Count the data engineers who can be committed to customer data for the next 18 months. Fewer than two full-time equivalents is a warning sign for a pure composable build.
- Model total cost over three years. Include warehouse compute growth for composable, profile or event-based license growth for packaged, and the internal labor for both. Warehouse-native pricing can surprise finance when activation volume grows; packaged pricing can surprise when profile counts cross a tier.
- Pilot with one journey end to end. Build one high-value journey, from source data to channel to measurement, in the candidate architecture. Eight weeks is usually enough to learn what the RFP never would. Define the customer experience metrics for the pilot before you start.
- Decide the hybrid explicitly. Most large enterprises end up with a warehouse-centered core plus a narrow real-time layer. That is a legitimate target architecture; the failure mode is arriving there by accident with three overlapping tools.
How long does a CDP implementation take?
Packaged CDP implementations in large enterprises have commonly taken six months or more from contract to the first production use case, with identity resolution and source integration as the long poles. Composable deployments can produce a first audience in weeks when the warehouse is mature, but if the identity graph does not exist, the engineering program to build it can take as long as a packaged rollout. Set expectations on the state of your data, not on the architecture label.
Key takeaways
- The three options differ mainly in where customer data lives, who operates it and how many copies you create.
- A warehouse is not a CDP, but a mature warehouse plus an activation layer is a composable CDP.
- Latency is the swing factor: most enterprise use cases run on daily data, and that favors composable.
- Operating capacity decides more projects than architecture does; count your data engineers honestly.
- Every extra copy of personal data is a privacy obligation; composable wins by default on that dimension.
- Pilot one journey end to end before committing, and choose any hybrid deliberately rather than by accumulation.
Join your peers at CustomerTech World 2027
CustomerTech World is the global meeting place for the leaders choosing the technology behind customer experience, with 750+ senior executives from 200+ organizations in each city and no product pitches on stage. Register for the city nearest you: Sydney, March 4 · Melbourne, March 18 · New York, May 13 · Los Angeles, May 19 · London, June 17.
Not ready to register? Sign up for updates and we will send the agenda as it is confirmed.