Composable CDP: when it beats a packaged one and how to choose

A composable CDP is the right choice when your warehouse is already the place where customer data is modeled, trusted and owned by a team that can run it. If that is not true yet, a packaged CDP gets you to activation with less engineering, and most packaged vendors now let you add warehouse-native audiences later. The criterion that decides more than any feature list: who will own the customer model, and in which system.

How I compared them. Criteria: where the customer profile and identity graph live, how fresh the audiences can be, which warehouses are supported, what the pricing is based on, and how much data-team work the setup needs. The data comes from each vendor's public documentation and pricing pages, read in October 2026; I link the page behind each claim. I have not tested these products for this guide, and I have not verified latency, match rates or total cost under real volumes.

You need a composable CDP if the warehouse already holds the customer model

"Composable" means the CDP does not keep its own copy of your customers. Profiles, identity and audience logic live in your warehouse (Snowflake, BigQuery, Databricks, Redshift), and the CDP layer reads from it and pushes audiences out to ads, email and CRM tools. A packaged CDP collects events, stores profiles in its own database and activates from there.

The composable model pays off when three prerequisites are already in place, not planned:

• Warehouse maturity. Customer, order and event tables are modeled (usually with dbt or an equivalent), tested and refreshed on a schedule that marketing can live with. If marketing does not trust the warehouse tables today, a composable CDP will put that distrust into every audience.
• A data team that owns the model. Someone has to define what a "customer", an "active subscriber" or a "churn risk" is in SQL, and maintain it when the business changes. In a composable setup that work does not disappear; it moves from the vendor to your team.
• An answer for identity resolution. You need a way to stitch anonymous IDs, emails, device IDs and CRM IDs into one person. Either your team builds it in the warehouse, or you buy it as a module (several vendors below sell one). Leaving identity for later means every audience built before it is decided will need rework.

A packaged CDP is usually enough when:

• you have no data warehouse, or it is used only for BI and nobody would trust it for activation;
• the main use cases are real-time, in-session personalization or triggered messages based on what the user did seconds ago;
• marketing needs to build audiences without asking a data team, and that team does not exist or is full.

For the wider picture of how collection, storage, identity and activation fit together, see customer data platform architecture.

Composable and packaged are now a spectrum, not two boxes

The 2026 market no longer splits cleanly. Reverse ETL vendors added audience builders, identity resolution and event collection. Packaged CDPs added zero-copy audiences that query your warehouse. In practice you choose a position on a spectrum:

1. Fully composable. Warehouse as the only store; an activation layer (Hightouch, Census) reads it.
2. Hybrid. A packaged CDP keeps real-time profiles for collection and in-session use, and builds batch audiences directly from warehouse tables.
3. Fully packaged. The CDP stores and activates everything; the warehouse gets a copy for analysis.

The hybrid option matters for the decision: if you already pay for Segment, mParticle, RudderStack or Tealium, check its warehouse-native mode before you add a second vendor. If reverse ETL itself is new to your team, what reverse ETL is and how it works covers the mechanism.

The criteria that matter, and how much they weigh in your case

Not every criterion weighs the same. A retailer with in-session personalization weighs latency far above a B2B team syncing account scores to the CRM once a day.

• Where the profile and identity graph live. In your warehouse, in the vendor's store, or both. Check: ask for the table schema of the identity output and where it is written.
• Audience freshness. Warehouse-native audiences run on a schedule; they are not streaming. Check: the documented minimum refresh interval, and what happens when a run is still going when the next one is due. Weighs most for triggered and in-session use cases.
• Supported warehouses. Not every feature works on every warehouse. Check: the vendor's support matrix for your warehouse, per feature (audiences, identity, write-back), not per product.
• Destinations and their depth. A connector to Meta Ads or Braze can mean very different things: which fields map, whether it handles deletes and audience exits, how it reports failures. Check: a live sync to your two most important destinations during the trial.
• Data quality and schema control. The activation layer sends whatever is in the table. Check: whether the vendor validates data before syncing, alerts on failed or partial syncs, and lets you stop a sync that suddenly sends far more rows than usual.
• Consent and deletion. Consent state has to travel with the profile into every destination, and a deletion request has to reach them all. Check: how consent fields are enforced at sync time, and how a deletion propagates.
• Warehouse compute cost. In a composable setup, every audience refresh is a query you pay for in your warehouse. Check: ask for the queries the vendor runs and estimate them against your warehouse pricing. This cost does not appear in the vendor's quote.
• Who operates it day to day. Check: can a marketer build and change an audience without writing SQL, and what still needs the data team?
• Pricing basis. Monthly tracked users, events, syncs, destinations or "usage". The basis decides how the bill grows. Check: model the next two years of growth against it.

Questions for the RFP

You can copy these as they are:

1. Where is the identity graph stored, and can I query it directly in my warehouse?
2. Which of your features work on [our warehouse], and which are limited or unavailable there?
3. What is the minimum refresh interval for a warehouse-based audience, and what latency should I expect end to end to [our main destination]?
4. Which queries do you run in my warehouse, how often, and how do I cap their compute cost?
5. Do you copy any customer data to your own infrastructure, even temporarily? Where, and for how long?
6. How does consent state reach each destination, and how is a deletion request propagated?
7. What happens when a sync fails halfway, or a source table suddenly changes size or schema?
8. What is your pricing based on, and what would the bill be at [current volume] and at twice that?
9. What can a marketer do without SQL, and what requires the data team?
10. If we leave, what stays in our warehouse and what do we lose?

Red flags

• "Warehouse-native" that is really a copy. If the vendor loads your warehouse tables into its own store to build audiences, you get the cost of both models. Ask for the data flow diagram.
• No answer on warehouse compute. A vendor that cannot tell you which queries it runs in your warehouse cannot help you control that cost.
• A support matrix that is "coming soon" for your warehouse. Decide on what exists today.
• Identity resolution as a slide, not a schema. If they cannot show you the output tables and the matching rules, assume your team builds it.
• Pricing you cannot model. If you cannot estimate next year's bill from the pricing basis and your own numbers, the negotiation starts in the vendor’s favor.

The vendors, by the job they do

Grouped by the job they do, and alphabetical within each group. All facts are from the linked official pages, as of October 2026.

Warehouse-native activation: reverse ETL that grew into a CDP

These started by syncing warehouse tables into business tools and added audience builders and identity on top. Your warehouse is the only store.

Census (Fivetran Activations)

• What it does: Reverse ETL from the warehouse to business tools, plus Audience Hub, a visual segment builder that needs no SQL, according to Fivetran's Activations documentation. Fivetran announced an agreement to acquire Census on May 1, 2025; Census's pricing page now redirects to Fivetran's, and Fivetran's docs include a guide to migrating Census accounts to its platform.
• Best for: Teams that already load data with Fivetran and want ingestion and activation from one vendor.
• Not for: Teams that need real-time event collection or a packaged profile store. Entity resolution is not mentioned in the Activations documentation: not verified.
• Pricing (public, October 2026): Partly public. Fivetran's pricing page has a free plan and shows usage-based rates and examples for activations; subscription prices for Standard, Enterprise and Business Critical are not public.
• Source: Fivetran Activations docs, Fivetran pricing.

Hightouch

• What it does: Sells a "Composable CDP" plan in which you pick modules: Reverse ETL, Hightouch Events, Customer Studio (audience builder), Real-time Personalization, Identity Resolution and Match Booster (pricing page). Its Identity Resolution writes resolved identities, mappings and a golden record as tables in your warehouse, with deterministic matching by default and probabilistic matching available.
• Best for: Teams with a mature warehouse and a data team that want the activation layer, and optionally identity, without a second customer store.
• Not for: Teams without a trusted warehouse. The documentation also says identity resolution processes some data outside the warehouse, which matters if your policy requires all processing to stay inside it.
• Pricing (public, October 2026): A free Basic Reverse ETL tier with up to 2 active syncs. Paid plans are usage-based and not public; the page says there are no MTU limits and no caps on sources, destinations or seats.
• Source: Hightouch pricing, Identity Resolution docs.

Packaged CDPs with a warehouse-native mode

These collect events and keep real-time profiles in their own platform, and now also build audiences from warehouse tables without loading them. The hybrid option.

mParticle

• What it does: A real-time CDP that, per its composable architecture page, can sit on top of your warehouse with "your warehouse remains the system of record". Composable Audiences are built in a no-code interface and refresh as often as hourly. The Warehouse Sync API ingests data from Snowflake, BigQuery, Redshift and Databricks. The site now brands it "mParticle by Rokt", after the merger with Rokt announced as a US$300 million deal.
• Best for: Teams that need real-time profiles for apps and web and want batch audiences from the warehouse in the same tool.
• Not for: Teams that only need batch activation from the warehouse; a pure activation layer is simpler. Warehouse audiences are not real-time.
• Pricing (public, October 2026): Not public ("Request pricing" on the pricing page).
• Source: Composable architecture, Warehouse Sync API.

RudderStack

• What it does: Event collection, warehouse destinations and Reverse ETL in every plan (pricing page). Profiles is a declarative framework: you define identity rules and features in version-controlled YAML and it generates warehouse SQL that builds a customer 360 table.
• Best for: Data teams that want collection and identity as code, versioned next to their dbt project.
• Not for: Marketing teams that expect to build identity and audiences in a visual interface without the data team. Profiles is listed only on the Enterprise plan.
• Pricing (public, October 2026): Free up to 250K events a month; Growth from $265 a month (starting at 1M events); Enterprise custom. Priced by monthly events.
• Source: RudderStack pricing, Profiles overview.

Segment

• What it does: Twilio's CDP: Connections (collection and delivery), Unify (profiles) and Engage (audiences and journeys). Linked Audiences combine Segment profile data with warehouse entity tables through a Data Graph, on BigQuery, Databricks, Redshift and Snowflake. They require Profiles Sync and the Business tier or an add-on, and the documented minimum run frequency is 15 minutes.
• Best for: Teams already on Segment for collection that want warehouse entities (accounts, subscriptions, products) in their audiences without a second vendor.
• Not for: Teams on the Free or Team tiers, where Linked Audiences are not available, or teams that want no vendor-held profile at all.
• Pricing (public, October 2026): The CDP is by quote ("Contact us for plan and add-on pricing"); pricing is based on monthly tracked users, per Twilio's pricing page.
• Source: Linked Audiences docs, limits, pricing.

Tealium

• What it does: Tealium's real-time CDP keeps visitor profiles for collection-time and in-session use. CloudStream is a segment builder that activates data from your data cloud (the docs name Snowflake and Databricks as examples) without storing or loading it into Tealium; data is imported only temporarily for activation. Tealium's documentation positions it for batch and warehouse activation.
• Best for: Teams that already run Tealium for tag management or real-time profiles and want warehouse audiences under the same governance.
• Not for: Teams that need a published support matrix before shortlisting: the product page names only Snowflake and Databricks. Tealium's documentation on cloud data sources lists Amazon Redshift, Databricks, Google BigQuery and Snowflake, and says CloudStream can use them; confirm your warehouse and connection method with Tealium before shortlisting.
• Pricing (public, October 2026): Not public.
• Source: CloudStream docs, CloudStream product page.

The same criteria, side by side

"Not verified" means I did not find it on the vendor's official pages in October 2026, not that the capability is missing. Ask in the RFP.

Where to start, by case

The facts above suggest a starting point per situation; the final call depends on your stack and your team.

• You already run a packaged CDP and the warehouse is maturing: test its warehouse-native mode first (Segment Linked Audiences, mParticle Composable Audiences, Tealium CloudStream, RudderStack Profiles). Adding a second vendor only makes sense if that mode fails your RFP.
• You have a mature warehouse, a data team and no CDP: start with a pure activation layer (Hightouch, Census) and add identity as a module or in your own models.
• You need in-session personalization: keep a real-time profile store, packaged or hybrid. Scheduled warehouse audiences do not cover that use case.

For how a CDP fits next to the other platforms in a marketing data stack, the marketing data platforms buyer's guide covers the reference architectures.

What to check this week: list the three audiences that drive most of your activation and write down which system computes each one today. If the answer is already "the warehouse" for all three, you are a composable candidate. If it is "the CDP" or "a spreadsheet", fix the warehouse model first.