MarketingMarketing Analytics

The composable CDP explained: what it really means to build on your data warehouse

The composable CDP promises to replace bloated customer data platforms with a leaner, warehouse-native architecture. Here is what that actually means in practice, and where the tradeoffs bite.

🎙️

Listen to the podcast

4 min

The term "composable CDP" has been circulating in marketing technology circles since roughly 2022, and it still generates more confusion than clarity. Vendors use it to mean different things. Analysts debate whether it is a product category or just an architectural pattern. And CMOs are left trying to decide whether to re-platform their customer data infrastructure based on marketing copy that rarely explains the underlying mechanics. The concept itself is straightforward once you strip away the positioning. The confusion mostly exists because it threatens the business model of established CDP vendors, who have understandable reasons to muddy the water.

Why it matters for CMOs specifically

Traditional CDPs, such as Segment, Salesforce Data Cloud, or Adobe Real-Time CDP, follow a similar pattern: you pipe your customer data into the vendor's proprietary storage, the vendor's tools build unified profiles, and your marketing systems query those profiles through the vendor's APIs. The vendor holds the data. You pay for storage, compute, and seats, often redundantly, because you are also paying for a data warehouse like Snowflake, BigQuery, or Databricks where most of your company's actual data already lives.

The practical consequence is that your customer data ends up split across systems. Your data science team runs churn models on Snowflake. Your marketing team runs audiences on Segment. Getting those two things to talk requires engineering effort, custom connectors, and ongoing maintenance. The split creates latency, inconsistency, and cost. IDC estimated in 2024 that enterprises managing more than three cloud data platforms faced integration costs averaging 23% of their total data infrastructure budget, a figure that has not improved as the number of platforms has grown.

A composable CDP reframes this entirely. Instead of moving your data into a vendor's proprietary store, you keep it in your existing data warehouse and run the CDP logic, profile unification, audience segmentation, identity resolution, on top of that warehouse using modular, interoperable tooling. The data never leaves your environment. The "composable" part refers to assembling the capabilities you need from specialized components rather than buying a monolithic platform that does everything inside its own walls.

For a CMO, this matters on three levels. First, cost: you stop paying double for storage. Second, control: your data science and marketing teams share the same underlying tables, so a propensity score built by a data scientist is immediately available to a marketing analyst building a campaign audience without any export or sync job. Third, vendor risk: your data is not locked inside a proprietary schema that becomes expensive to migrate away from.

How it actually works: the mechanics

Take a mid-sized retailer running Snowflake as their cloud data warehouse. Their transactional data, web clickstream, loyalty program records, and call center logs all land in Snowflake through standard ingestion pipelines. In a traditional CDP setup, they would then export a subset of that data into, say, Segment, which would build unified customer profiles in Segment's own infrastructure. Segment would then push audience lists to Meta, Google, Klaviyo, and so on.

In a composable architecture, the profile unification happens inside Snowflake itself. A tool like Hightouch (which markets a "data activation" platform, so treat their benchmarks with appropriate skepticism) or Census reads the tables already in Snowflake, applies identity resolution logic configured by the data team, and writes unified profile tables back into the warehouse. Those profiles are then synced directly to Meta, Google, or Klaviyo using reverse ETL, a process that pushes warehouse data to downstream tools rather than pulling data into a central platform.

The audience builder, the component that lets a marketing analyst say "give me all customers who bought in the last 90 days but have not opened an email in 60 days," runs as a SQL query or a visual interface on top of Snowflake. The result is a segment that exists as a table or view in the warehouse, versioned and auditable, and then activated to the relevant channels through the reverse ETL layer.

Identity resolution, often cited as the hardest part of any CDP implementation, is handled by specialized components like Reltio or Amperity, which can operate against your warehouse data rather than requiring you to pipe everything into their own stores. This is where "composable" gets genuinely complicated: you are assembling multiple vendors, each with their own configuration, support contracts, and failure modes. The total integration surface is wider than a monolithic CDP, even if the data footprint is smaller.

When to use it and when not to: the honest tradeoffs

A composable approach makes most sense when your organization already has a mature data warehouse and a data engineering team capable of maintaining the pipelines connecting it. If Snowflake or BigQuery is already the canonical source of truth for your business, and your data team is competent, the marginal cost of adding composable CDP tooling on top is low. You are not building a new data foundation; you are adding an activation layer.

It makes considerably less sense for organizations where marketing owns its own data stack in isolation from engineering, or where the data warehouse is poorly governed and inconsistently populated. The composable model assumes the warehouse is trustworthy. If your Snowflake environment has unresolved identity duplication, inconsistent event schemas, or stale data from unreliable pipelines, a composable CDP will faithfully expose all of those problems to your marketing campaigns. A traditional CDP, for all its costs, at least applies its own data quality layer before activation.

The other honest caveat is time-to-value. A monolithic CDP like Segment or Adobe Real-Time CDP ships with pre-built connectors, identity graphs, and audience tools that work reasonably well out of the box. A composable stack requires assembly. An enterprise retailer moving from a traditional CDP to a composable architecture should budget six to twelve months of engineering work before the setup is stable enough to rely on for time-sensitive campaign execution.

The composable CDP is a sound architectural direction for organizations with the data maturity to support it, not a shortcut. If your warehouse is the center of gravity for your business data, building your customer data capability there rather than duplicating it in a vendor's proprietary system is the more defensible long-term choice. The companies getting the most from this model, including several large European retailers and U.S. financial services firms, share one characteristic: they treated the warehouse as infrastructure strategy before they treated composable CDP as a marketing technology decision.

Finished reading?

Validate your read to earn XP and feed your radar.