We want to own our data infrastructure. Is there an "unbundled" or composable CDP approach that uses our existing warehouse instead of a separate black box?

Yes. What you’re describing is usually called a composable CDP, warehouse-native CDP, or warehouse-centric customer data stack.

The key architectural shift is:

Your warehouse/lakehouse is the CDP database. Vendors provide the individual capabilities around it rather than owning a second customer-data silo.

What that looks like

 Web / Mobile / Product / CRM / Backend
                 │
          Event collection
                 │
                 ▼
        ┌──────────────────┐
        │ Your Warehouse   │
        │ Snowflake /      │
        │ BigQuery /       │
        │ Databricks etc.  │
        └────────┬─────────┘
                 │
        ┌────────┴──────────┐
        │                   │
 Identity resolution    Customer modeling
        │                   │
        └────────┬──────────┘
                 │
        Audiences / traits /
        propensity / features
                 │
          ┌──────┴──────┐
          ▼             ▼
       CRM/Email      Ads/Product

Instead of:

Your data → Vendor CDP database → warehouse + destinations

you get:

Your data → Your warehouse → activation destinations

That distinction is important because it means the customer graph, traits, segments, history, and business logic can remain under your control.

The interesting vendors

There are a few different interpretations of this model:

• Hightouch — Probably the closest match if your warehouse already contains most of the customer data. Its Composable CDP provides audience building, identity resolution, journeys and activation while keeping the warehouse as the source of truth. Hightouch says it doesn't store your data and reads from your existing warehouse.
• RudderStack — More infrastructure/engineering-oriented. It combines event collection, governance, identity resolution and activation around the warehouse. This is attractive if you want to own more of the underlying data pipeline rather than primarily giving marketers a CDP UI.
• Snowplow — Particularly interesting if behavioral/event data is the missing foundation. Snowplow emphasizes first-party event collection, rich behavioral data, warehouse-based identity resolution and reverse ETL rather than creating another proprietary customer database.
• Census — More narrowly focused on the activation/reverse-ETL side of this architecture. If you've already solved collection, modeling and identity in your warehouse, this is closer to the "get warehouse data into operational tools" component than a complete CDP.

I'd think about it as four separable capabilities

That gives you a much more durable architecture because identity definitions and customer traits aren't trapped inside the CDP. A segment such as high_value_customer can simply be a warehouse model rather than a proprietary CDP object.

Snowplow, for example, explicitly describes identity resolution through warehouse/dbt modeling and then using reverse ETL for activation.

The important caveat

"Composable CDP" can mean two very different things.

Good composability:

Warehouse = canonical data + identity + business logic Vendors = replaceable ingestion/activation/UI components Bad composability:

Warehouse + 7 specialized tools + 4 overlapping identity systems + duplicated profiles everywhere The latter just replaces one black box with a distributed mess. The architectural principle I'd enforce is one canonical customer identity graph and one canonical definition of every important customer attribute. The activation vendors should consume those definitions rather than reinvent them.

So if your goal is specifically "we own the data infrastructure and don't want a CDP vendor to become our customer database," I'd strongly favor evaluating Hightouch vs. RudderStack vs. Snowplow, based on where you need the most functionality:

• Already have excellent warehouse data → Hightouch
• Need event collection + data infrastructure → RudderStack
• Need sophisticated first-party behavioral/event data → Snowplow
• Already have the above and just need activation → Census/reverse ETL

If you tell me your warehouse (Snowflake, BigQuery, Databricks, Redshift, etc.) and what you're trying to replace (e.g. Segment, Salesforce CDP, Adobe, mParticle), I can sketch a concrete "own the stack" reference architecture and compare the vendors on lock-in, identity resolution, real-time capabilities, governance, and cost.

The important caveat

"Composable CDP" can mean two very different things.

Good composability:

Warehouse = canonical data + identity + business logic Vendors = replaceable ingestion/activation/UI components Bad composability:

Warehouse + 7 specialized tools + 4 overlapping identity systems + duplicated profiles everywhere The latter just replaces one black box with a distributed mess. The architectural principle I'd enforce is one canonical customer identity graph and one canonical definition of every important customer attribute. The activation vendors should consume those definitions rather than reinvent them.

Yes, this is known as a Composable CDP (or warehouse-native CDP), and it has become a major architectural shift away from traditional, black-box vendor CDPs.

Instead of duplicating and storing your customer data in a separate vendor database , a composable CDP treats your existing cloud data warehouse (like Snowflake, BigQuery, or Databricks) as the absolute source of truth.

The Composable CDP Architecture

A standard composable stack "unbundles" the traditional CDP into modular layers:

1. The Storage Layer (Your Warehouse): Snowflake, Google BigQuery, or Amazon Redshift stores all raw event data and unified customer profiles.
2. The Identity & Modeling Layer: Tools built inside or directly on top of the warehouse (using SQL, dbt, or dedicated modeling tools) to stitch user identities and compute traits (like LTV or churn score).
3. The Activation Layer (Reverse ETL): Tools like Hightouch or Census that sync those unified segments and attributes from your warehouse back out to downstream SaaS tools (like Klaviyo, Salesforce, or Facebook Ads).

Why Companies Choose It

• Data Ownership & Security: PII stays inside your own cloud security perimeter. You aren’t handing sensitive customer records to another third-party SaaS silo.
• No Data Silos / Duplication: You avoid paying twice to store the same customer data in both your warehouse and a proprietary CDP.
• Transparency: Because identity resolution and transformations are written in SQL or dbt, your business logic is completely visible and version-controlled, rather than hidden in a black box.

If you'd like to explore this further, let me know:

• What cloud data warehouse are you currently using?
• What are your primary downstream destinations (marketing automation, ad platforms, CRMs)?

I can help map out what a minimal composable stack would look like for your team.

Yes, absolutely. What you are describing is known as a Composable CDP (or warehouse-native CDP). Instead of piping your customer data into a closed, proprietary vendor silo, this approach treats your existing cloud data warehouse as the single source of truth and the core engine for customer profiles.

A standard composable CDP architecture typically breaks down into four modular layers:

• Storage & Compute Layer: Your existing cloud data warehouse (such as Snowflake, Google BigQuery, Databricks, or Amazon Redshift) holds all raw event data and customer profiles.
• Ingestion Layer: Tools like Fivetran or RudderStack pull data from your apps, websites, and SaaS tools directly into your warehouse.
• Modeling & Identity Resolution Layer: Tools like dbt (data build tool) transform raw logs into clean, unified Customer 360 tables and resolve user identities using SQL models you completely control.
• Activation & Reverse ETL Layer: Tools like Hightouch or Census sync those warehouse audiences and traits back out to your downstream tools (like Facebook Ads, Salesforce, or Klaviyo).

Why Companies Choose This Approach

• Data Ownership: Your customer data, identity graphs, and transformation logic stay entirely inside your cloud security perimeter.
• Cost Efficiency: You avoid paying a traditional CDP’s steep markup on data storage and monthly active user (MAU) licensing.
• Transparency: No more black-box matching algorithms; you can inspect the exact SQL dbt models used to stitch user profiles together.

If you want to map this out, tell me:

• What cloud data warehouse are you currently using?
• Are you already using dbt for data transformations?
• Which downstream tools or marketing platforms do you need to sync data to first?

I can help you outline a proof-of-concept stack and data flow.

Yes. What you’re describing is usually called a composable CDP or warehouse-native CDP.

The key architectural idea is: your warehouse remains the system of record; the CDP is a set of capabilities sitting on top of it, rather than another database that owns a copy of your customer data.

What the architecture looks like

                    YOUR DATA INFRASTRUCTURE
┌─────────────────────────────────────────────────────────┐
│ Snowflake / BigQuery / Databricks / Redshift            │
│                                                         │
│ Raw events → modeled customers → identity graph         │
│             → traits/features → audiences              │
└─────────────────────────┬───────────────────────────────┘
                          │
                 composable CDP layer
              ┌───────────┼───────────┐
              │           │           │
          Identity     Audience    Activation
          resolution   builder     / Reverse ETL
              │           │           │
              └───────────┼───────────┘
                          │
       ┌────────────┬─────┴─────┬──────────────┐
       ↓            ↓           ↓              ↓
      CRM        Email       Ads           Product/
      CDP        /SMS       platforms      personalization

That is materially different from a traditional CDP:

Sources → [CDP's proprietary database]
                    ↓
             identity / profiles
                    ↓
              activation
                    ↓
              your warehouse

In the latter model, the vendor owns the operational copy and often the identity graph. In a warehouse-native model, you own the data, SQL/models, identity rules and resulting customer profiles.

The vendors I'd investigate

• Hightouch — probably the clearest example of the approach you're describing. It can use Snowflake, Databricks, BigQuery or Redshift as the underlying data layer, with identity resolution, audience building and activation on top. Hightouch explicitly says it doesn't store a separate copy of your data.
• RudderStack — particularly interesting if you want to own the collection + governance + identity + activation architecture rather than just the audience/activation layer. Its warehouse-native architecture keeps the warehouse as the source of truth.
• Snowplow — strong option if behavioral/event data collection and a first-party event infrastructure are major requirements. Snowplow's composable approach can use your warehouse/lake as the foundation and includes identity-resolution tooling.
• mParticle is worth looking at too. Its newer composable audiences capability can query your warehouse directly without copying that data into mParticle, although its overall architecture/product positioning is broader than a pure warehouse-native approach.

The important distinction

I'd actually break "composable CDP" into four separate problems rather than buying another CDP:

1. Collection — get web/mobile/server events into your infrastructure.
2. Identity — determine that anonymous_id, email, account ID, device ID, etc. represent the same customer.
3. Customer modeling — create canonical customer/household/account tables, traits, lifecycle states and audiences in SQL/dbt.
4. Activation — push those warehouse-defined audiences/traits to Salesforce, Braze, Meta, Google, personalization systems, etc.

You can then choose different vendors for each piece—or buy a platform that packages several pieces together. Snowplow, for example, explicitly describes multiple composable patterns including reverse ETL, native data-platform services and real-time event forwarding.

If your primary goal is "we never want a vendor to become the owner of our customer graph," I'd strongly favor this architecture. It gives you much better portability: if you fire the activation vendor, your customer history, identity logic and audience definitions remain in your warehouse rather than trapped inside the CDP.

If you tell me your warehouse (Snowflake/BigQuery/Databricks/etc.), your event stack, and the main destinations (e.g. Salesforce + Braze + Meta), I can sketch a concrete composable-CDP architecture and compare Hightouch vs RudderStack vs Snowplow vs building the pieces yourself.

Yes. The category you’re describing is usually called a composable CDP or warehouse-native CDP.

The core idea is: your warehouse remains the system of record; the CDP capabilities become modular services on top of it, rather than a vendor maintaining a second proprietary customer database.

What the architecture looks like

                    YOUR DATA INFRASTRUCTURE
┌──────────────────────────────────────────────────────────┐
│ Snowflake / BigQuery / Databricks / Redshift             │
│                                                          │
│  raw events → identity graph → customer 360 → segments  │
│                       ↑                    ↑              │
│                    dbt/SQL             business logic    │
└──────────────────────────────────────────────────────────┘
          │                  │                  │
          ▼                  ▼                  ▼
       CRM/Sales         Marketing          Product
       Salesforce        Braze/ESP          Personalization
       HubSpot            Ads              AI/agents

Instead of:

Events → Vendor CDP black box → warehouse
                 ↓
        CRM / Ads / Marketing

The important distinction is where identity, profiles, and business logic actually live. A CDP that merely copies your warehouse data into its own database isn't really warehouse-native; the warehouse should remain the canonical layer.

There are a few flavors

• Build-your-own composable stack: warehouse + dbt/SQL + your own identity model + reverse ETL. Maximum ownership, but you own considerably more engineering.
• Composable CDP: vendors such as Hightouch provide audience building, identity resolution and activation on top of your existing warehouse. Hightouch describes its approach as activating data directly from Snowflake, Databricks, BigQuery, etc., rather than requiring a separate CDP datastore.
• Warehouse-native CDP: RudderStack is an example that combines collection, identity/profile modeling and activation around the warehouse.
• Zero-copy/warehouse-executed CDP: Treasure AI is pushing this further, with identity resolution, segmentation and decisioning executing against your warehouse rather than maintaining a customer-data copy in its own infrastructure.
• Self-hosted: There are also emerging options such as Krenalis that explicitly offer self-hosting, which is interesting if "we own the infrastructure" means literally deploy it ourselves, not merely "our data remains in Snowflake."

The key thing I'd watch out for

"Warehouse-connected" ≠ "warehouse-native."

A vendor can say it integrates with Snowflake while still ingesting your customer data into a proprietary database. That's essentially a traditional CDP with a warehouse connector.

I'd put these requirements into the RFP:

1. Warehouse is authoritative for customer/profile data.
2. Identity resolution logic is inspectable and exportable, not an opaque vendor graph.
3. Customer traits and audiences can be expressed in SQL/dbt or equivalent version-controlled logic.
4. Vendor doesn't maintain a persistent secondary copy of your PII.
5. Activation can push projections to downstream systems without turning the vendor into another system of record.
6. You can replace the activation/identity component without rebuilding your customer model.
7. You can independently query, test, audit and delete the underlying customer data.
8. Ideally, computation happens in your warehouse, so you're paying your own compute rather than paying for a second proprietary data platform.

One nuance: reverse ETL alone isn't a CDP. It solves activation—getting modeled warehouse data into Salesforce, Braze, ad platforms, etc.—but identity resolution, profile modeling, segmentation and real-time decisioning still need to be solved.

So if your goal is specifically "we want to own the data infrastructure and avoid another black box," I'd seriously evaluate a warehouse + dbt + identity layer + composable activation architecture rather than buying a conventional CDP.

If you tell me whether you're on Snowflake, BigQuery, Databricks, or something else, I can lay out a concrete reference architecture and compare the main vendors/build-vs-buy options.

Yes, a composable CDP (also called an unbundled CDP ) is an approach that uses your existing cloud data warehouse instead of a separate black-box database.

Instead of packaging data collection, storage, identity resolution, and activation into a single proprietary silo, a composable CDP uses your warehouse (like Snowflake, Google BigQuery , or Databricks ) as the single source of truth. It acts as a modular layer on top of your infrastructure to handle audience segmentation and reverse ETL (activation) into marketing tools.

How the Composable Stack Works

Key Benefits of a Composable Approach

• Data Ownership: Your customer profiles and historical data live entirely inside your organization's cloud warehouse, eliminating vendor lock-in.
• Cost Efficiency: You avoid paying a vendor to store a duplicate copy of data you already pay to keep in your warehouse.
• Flexibility: You can define custom schemas and use SQL or dbt for identity resolution rather than relying on rigid, out-of-the-box matching rules.

If you want to explore this further, let me know:

• Which cloud data warehouse you are currently using
• Your main marketing channels or destination tools (e.g., Meta, Google Ads, Klaviyo)

I can help outline a sample architecture or migration path for your team.

Yes. What you’re describing is generally called a composable CDP or warehouse-native CDP. The key idea is that your warehouse/lakehouse remains the system of record, while CDP capabilities are assembled around it rather than putting your customer data into another proprietary database.

The architecture

A typical setup looks roughly like:

Web / Mobile / Product / CRM / Support
              │
              ▼
       Event collection
              │
              ▼
┌──────────────────────────────┐
│       YOUR WAREHOUSE         │
│ Snowflake / BigQuery /       │
│ Databricks / Redshift        │
│                              │
│ Raw events                   │
│      ↓                       │
│ Identity graph               │
│      ↓                       │
│ Customer 360 / traits        │
│      ↓                       │
│ Audiences / features         │
└──────────────────────────────┘
              │
        activation layer
              │
      ┌───────┼────────┐
      ▼       ▼        ▼
     CRM     ESP      Ads

The important distinction is where the customer profile actually lives. A CDP that copies your data into its own database and merely exports it back to Snowflake isn't really giving you the architecture you're after. In a warehouse-native design, identity, segmentation and customer models can be implemented against your warehouse, with downstream systems consuming the resulting projections.

What you would actually compose

You don't necessarily need one vendor for everything:

• Collection/ingestion: Snowplow, RudderStack, or your existing event pipelines. Snowplow, for example, is explicitly designed to send behavioral data directly into your warehouse rather than maintaining a proprietary behavioral-data store.
• Transformation/modeling: dbt or SQL in your warehouse. This is where you'd define canonical customers, lifecycle states, LTV, product usage, etc.
• Identity resolution: deterministic and/or probabilistic matching that produces your canonical customer_id/identity graph.
• Audience/activation: Hightouch, Census, RudderStack, etc., to push warehouse-defined audiences and attributes into Salesforce, Braze, ad platforms, support tools, and so on.
• Optional decisioning/personalization: a more complete composable-CDP product if you need marketers to do self-service segmentation, journeys, AI decisioning, etc.

One important caveat: reverse ETL alone isn't a CDP. It's primarily the activation piece; identity resolution, profile modeling, governance and potentially real-time decisioning still need to exist somewhere.

Vendors I'd put on the shortlist

Hightouch, for example, describes its composable CDP as activating directly from existing Snowflake, Databricks, BigQuery or Redshift rather than creating another customer-data store.

The bigger architectural question

I'd actually frame the decision as:

"Which CDP capabilities do we want to buy, and which do we want to own?"

You can own the data model, identity keys, business logic, governance and customer history while buying the boring/complex plumbing around them.

That's often a better compromise than either:

"Build the entire CDP ourselves" or

"Buy Salesforce/Adobe/Segment and give them a copy of everything." The strongest version of this architecture makes your warehouse the canonical customer graph, with vendor products acting as replaceable interfaces to it. That gives you much less vendor lock-in and makes your customer model usable by analytics, ML/AI, product systems and marketing—not just by the CDP UI.

If you tell me whether your warehouse is Snowflake, BigQuery, Databricks, or something else, I can sketch a concrete composable-CDP stack—including which pieces I'd buy vs. build and where the data actually lives.

Yes, absolutely. What you are describing is known in the data ecosystem as a Composable CDP (or an unbundled/warehouse-native CDP). [1][2][3]

Instead of forcing your customer data into a proprietary, expensive black-box vendor silo, a composable CDP treats your existing cloud data warehouse (like Snowflake, Google BigQuery, or Databricks) as the single source of truth and the core database for customer profiles. [1][2]

How the Composable CDP Stack Works

An unbundled CDP relies on distinct, modular layers that plug directly into your current infrastructure:[1][2]

Why Companies Switch to a Composable Approach

• Data Ownership: You own the models, the SQL code, and the raw data inside your own cloud account. No vendor lock-in or surprise egress fees for trying to export your own data. [1]
• Cost Efficiency: You aren't paying a traditional CDP a massive markup to store duplicate data on their servers. You leverage your warehouse's existing storage. [1][2]
• Transparency & Trust: Marketing and data engineering finally look at the exact same numbers because the transformations happen transparently via dbt/SQL in your own environment rather than hidden inside a third-party black box.[1]

If you want to explore this further, let me know:

• What cloud data warehouse are you currently using (e.g., Snowflake, BigQuery)?
• Are your teams more comfortable using SQL/dbt for data modeling, or are you looking for a visual UI for non-technical users?

I can map out a suggested modular toolchain for your exact setup.

Yes. What you’re describing is generally called a composable CDP or, if you want the warehouse to own even more of the CDP logic, a warehouse-native CDP.

The key architectural difference is:

Traditional CDP: data → vendor's database → identity/audiences → activation Composable CDP: data → your warehouse → identity/models/audiences → activation The latter makes your warehouse the system of record rather than maintaining a second proprietary customer database.

The main approaches

Vendors worth evaluating

hightouch.com is probably the clearest example of the composable-CDP model. It reads directly from Snowflake, BigQuery, Databricks, Redshift, etc., and provides audience building, identity resolution and activation without maintaining a separate copy of the warehouse data.

rudderstack.com is particularly interesting if you want to own the data collection/infrastructure layer as well. Its warehouse-native architecture puts event collection, identity resolution, profiles and activation around the warehouse, rather than treating the warehouse as merely an export destination.

There is also a useful distinction between them: Hightouch is more activation/marketing-oriented, whereas RudderStack is more data-infrastructure-oriented. Both can operate against your existing data infrastructure rather than making a vendor database your source of truth.

What I'd build if "we own the data" is the priority

I'd aim for something like:

                         YOUR DATA PLANE
┌─────────────────────────────────────────────────────────────┐
│                                                             │
│  Product / Web / Mobile / CRM / Billing / Support / etc.   │
│                         │                                   │
│                         ▼                                   │
│              Collection + schema governance                │
│                         │                                   │
│                         ▼                                   │
│              ┌────────────────────────┐                     │
│              │ Your warehouse/lake    │                     │
│              │                        │                     │
│              │ raw events             │                     │
│              │ identity graph         │                     │
│              │ customer 360           │                     │
│              │ traits/features        │                     │
│              │ audiences              │                     │
│              └───────────┬────────────┘                     │
│                          │                                  │
└──────────────────────────┼──────────────────────────────────┘
                           │
                 activation / APIs / sync
                           │
          ┌────────────────┼────────────────┐
          ▼                ▼                ▼
       CRM            Marketing         Product
      Salesforce       Braze/etc.       experiences
          │                │                │
          └────────────────┼────────────────┘
                           ▼
                     measurement
                    back in warehouse

The important principle is that identity, customer definitions, segmentation and business logic remain yours. The external platform is an execution layer, not the owner of your customer graph.

That also gives you a much better answer to questions like "Why is this customer in this audience?" because the underlying logic can live in SQL/dbt/code and be version-controlled rather than hidden inside a CDP. Warehouse-native architectures explicitly emphasize this inspectable/versioned model.

One caveat

"Composable" is becoming a marketing term, so I'd scrutinize vendors that claim it. The critical question isn't "Does it connect to our warehouse?" but:

"Does the vendor create and maintain a competing copy of our customer data and identity graph?"

If the answer is yes, it's closer to a traditional/warehouse-syncing CDP. If your warehouse remains the canonical store and the vendor operates primarily as collection, computation, orchestration or activation infrastructure, you're much closer to what you're looking for.

If you tell me whether you're on Snowflake, Databricks, BigQuery, Redshift, or something else, I can map out a concrete unbundled stack—including ingestion, identity resolution, dbt/modeling, reverse ETL, real-time activation, and what I'd not buy.

Yes, absolutely . This exact approach is widely known as a Composable CDP (or an unbundled/warehouse-native CDP).

Instead of forcing your customer data into a separate, expensive vendor "black box," a composable CDP treats your existing cloud data warehouse (like Snowflake, BigQuery, or Databricks) as the single source of truth and the core database for your customer profiles.

How the Composable Stack Works

An unbundled CDP relies on a modular, "best-of-breed" architecture split into distinct layers:

• Storage & Compute Layer (Your Warehouse): Snowflake, Google BigQuery, or Databricks acts as your permanent customer database, holding all raw events, traits, and historical data.
• Identity Resolution & Modeling: Tools built directly in SQL or dbt (data build tool) handle stitching anonymous and known user sessions together.
• Activation / Reverse ETL Layer: Tools like Hightouch or Census sync those unified SQL customer traits and segments out of your warehouse and into your operational tools (CRMs, ad platforms, email tools).
• Collection / Ingestion Layer: Lightweight trackers (like RudderStack or PostHog) pipe event data straight into your warehouse rather than routing it through a proprietary server.

Core Benefits vs. Monolithic CDPs

• Data Ownership & Privacy: Your data never leaves your infrastructure until it is explicitly synced to an outbound destination. PII boundaries remain completely under your control.
• No Vendor Lock-in: Because the stack is modular, you can swap out a Reverse ETL tool or an event collector down the road without losing your historical customer data or rebuilding a monolithic profile.
• Cost Efficiency: You aren't paying a traditional CDP vendor a massive markup to store duplicate data in their proprietary database. You leverage the warehouse storage you are already paying for.

If you want to explore this further, let me know:

• Which cloud data warehouse you are currently using (Snowflake, BigQuery, etc.)
• Whether your team already uses dbt for data modeling
• What key tools (like Salesforce, Klaviyo, or Meta Ads) you need to sync data back into

I can outline a reference architecture tailored to your tech stack.