What Is a Composable CDP? A Guide

The composable CDP is the hottest architecture debate in the customer data space right now. Warehouse-native vendors have published dozens of pages arguing that traditional CDPs are dead and your data warehouse should be your CDP. Traditional vendors fire back that "composable" is just a rebrand of reverse ETL with better marketing. And both sides are making arguments that only matter if you already have a data warehouse and a data engineer to operate it.

If you want background on what a CDP is and the three main architectures, we covered that in depth already. This post answers a more specific question: what is a composable CDP, really? Where the hype diverges from reality, and the follow-up question neither side of the debate wants to ask: what about the team that doesn't have a warehouse at all?

What a composable CDP is and how it works

A composable customer data platform is a modular CDP that runs on top of your existing cloud data warehouse. Instead of buying a bundled platform that handles data collection, storage, identity resolution, and activation in one package, you assemble those capabilities from separate tools that all read from and write to your warehouse.

The architecture looks like this:

The warehouse is the foundation. Everything else plugs in on top.

The composable approach gained traction because it solves a real problem with traditional CDPs. When you buy a packaged platform, you are duplicating your data into another vendor's infrastructure. That means paying twice for storage, maintaining two sources of truth, and conforming your data to whatever schema the vendor prescribes. If you already invested $50,000-500,000 a year in building out a warehouse with clean, modeled customer data, routing it through a second proprietary store feels redundant.

Warehouse-native CDP vendors saw that frustration and built an activation layer that queries your warehouse directly. No data duplication. No second source of truth. Your marketing team gets a visual audience builder that reads from the same tables your analytics team uses for dashboards.

That much is genuinely useful. Where things get murky is the prerequisite list.

Why a composable CDP still requires a data warehouse

Every guide on this topic breezes past the same assumption: you already have a cloud data warehouse with modeled customer data inside it.

In practice, that means you need:

• A warehouse instance. Snowflake, BigQuery, Databricks, or Redshift. Compute and storage costs range from $500 to $5,000+ per month depending on data volume.

• Data pipelines into the warehouse. ETL or ELT tools that pull data from your SaaS tools and load it into warehouse tables. These have their own licensing costs and require configuration.

• A data model. Raw data in a warehouse is not useful for audience building. Someone needs to write dbt models or SQL transformations that shape your event data into customer profiles, session tables, and business-specific schemas.

• A data engineer (or equivalent). Someone who can set up the pipelines, write the models, maintain the schema as your business changes, and debug issues when syncs break.

Add the activation layer on top of that, and you're looking at a minimum of three to five tools, $2,000-10,000/month in infrastructure, and at least one technical person dedicated to keeping it running.

That matches what I hear from teams evaluating CDPs. The composable architecture is powerful, but only when the foundation is already in place.

For a 200-person company with a data team and an established warehouse, this is a reasonable stack. For a 25-person startup that needs Stripe data in HubSpot, it's like building a highway to drive to the grocery store across the street.

Composable CDP vs. traditional CDP vs. direct sync: which fits your team

Every comparison between these two architectures follows the same script: one side argues for warehouse-native flexibility, the other for managed simplicity. That framing leaves out a third option that most comparison pages skip.

Traditional CDPs bundle everything into a managed platform. You get simplicity in exchange for vendor lock-in and high costs. The composable approach gives you flexibility and data ownership in exchange for infrastructure responsibility. Both approaches assume you have the technical resources to implement and maintain them.

The composable vs. traditional CDP debate ignores a gap: what if you just need your tools to share data and you don't want to build a warehouse to make it happen?

One traditional CDP vendor wrote a piece arguing that "composable" has been conflated to mean too many different things, and that the term is mostly clever product marketing by warehouse-native CDP vendors. They're not wrong about the marketing spin. But their counter-argument is still aimed at enterprise buyers choosing between two architectures that both cost five to six figures. Nobody in that debate is addressing the 15-person company with a Postgres database, HubSpot, Stripe, and no interest in provisioning Snowflake.

When a composable CDP makes sense (and when it's overkill)

This architecture is the right choice when you check most of these boxes:

• You already operate a cloud data warehouse with modeled customer data

• Your data team has dbt models, SQL transformations, and pipeline monitoring in place

• Your marketing team needs to build audiences from warehouse data for multi-channel campaigns

• You want to avoid duplicating data into a second vendor-managed store

• You have at least one data engineer who can maintain the composable stack

If that describes your company, the composable approach is probably a better investment than a traditional packaged CDP. You avoid data duplication, you retain ownership of your customer data, and you can swap individual components without ripping out the entire platform.

But here is what I keep running into when I talk to teams evaluating this architecture: most of them don't have a warehouse yet. They heard that composable is the modern approach, assumed it would be simpler than a traditional CDP, and only discovered the warehouse prerequisite after starting the evaluation. The marketing pages are very good at showing the architecture diagram and less good at explaining what you need to build before the architecture diagram becomes reality.

I think the category will keep growing for mid-market and enterprise companies. For teams under 50 people, or teams without warehouse infrastructure, a composable customer data platform is probably not worth the investment. Not because the architecture is bad. Because the prerequisite list is too long for what the team actually needs.

How to get composable CDP benefits without the warehouse prerequisite

The core promise of the composable architecture is sound: modular, no vendor lock-in, use the tools you already have. The problem is that "the tools you already have" is assumed to include a data warehouse, and for most small teams, it doesn't.

We built Oneprofile around a different version of that same principle. Instead of requiring a warehouse as the central hub, Oneprofile connects the tools you actually have: your CRM, billing system, support platform, marketing tools, and your Postgres database if you have one. Data syncs bidirectionally between them on a schedule, with field-level change tracking and deterministic identity resolution built in.

What you get that overlaps with the composable promise:

• Modular: connect only the tools you use, add more later

• No data duplication into a vendor-managed black box

• Unified customer profiles across every connected tool

• Audience segmentation based on unified profile data

What you give up compared to a full composable stack: SQL-based audience building on warehouse data, probabilistic identity resolution across anonymous sessions, and the ability to run custom dbt models against a centralized data store. If your marketing team needs to build audiences with 20 conditions against terabytes of behavioral data, a warehouse-native CDP on Snowflake handles that. But for teams that just need every tool to agree on which plan a customer is on, the warehouse adds cost and complexity without adding value.

This debate is ultimately about architecture for companies with data teams. For the rest of us, the question is simpler: do your tools share data? If the answer is no, the fastest fix is connecting them directly.