DEV Community: Krenalis

The real CDP decision: where should your customer profile live?

Marco Gazerro — Mon, 06 Jul 2026 12:18:27 +0000

Most CDP discussions I see start with features: connectors, audience builders, identity resolution, real-time events, and reverse ETL. But the harder question usually sits one level below the feature list: where should the customer profile actually live?

Imagine an AI assistant preparing a next-best-action suggestion for a sales rep. It can see signals from the CRM, billing, product usage, and the warehouse, but those systems may not agree on what the customer is doing or which state the account is really in. Before the assistant can recommend anything useful, the company has to decide which customer profile should be trusted, and where that profile should be built.

This is the basic prerequisite behind many AI use cases in marketing, sales, and customer success: a reliable view of the customer.

Whether the use case is an assistant that suggests the next best action for a sales rep, a workflow that prioritizes accounts at risk, or a campaign that adapts its message to product usage, they all need the same basic thing. They need to know who the customer is, what they did, which systems know something about them, and which version of that information should be trusted.

That sounds obvious until you look at how customer data usually lives inside a company. The CRM may hold contact and account details, billing may know the plan and payment history, the product database may have users and events, while support, email, and analytics tools each keep their own useful but partial view. Somewhere there may also be a data warehouse, where some or all of these signals are copied, modeled, and analyzed.

At that point, “the customer” is not a single record. It is closer to a distributed system, and this is the kind of problem Customer Data Platforms were created to solve.

The real CDP decision is not only which tool has the best connectors or audience builder. It is where the customer profile should live.

What a CDP is really doing

A Customer Data Platform, or CDP, is a system that collects customer data from different sources, connects records and identifiers that belong to the same person or account, builds customer profiles and segments, and makes those profiles available to other tools.

In practice, most CDPs deal with four broad jobs: collecting data, resolving identities, building profiles or audiences, and activating those audiences in downstream systems such as CRMs, email tools, ad platforms, support tools, or product engagement platforms.

For example, a CDP may receive an anonymous web event, later connect it to a logged-in user, enrich that user with CRM and billing data, place the user into a segment, and sync that segment to a marketing automation tool.

The value is easy to understand. Instead of every tool keeping its own partial view of the customer, the company gets a more coherent customer profile that can be used across teams.

The important question is not whether this is useful. It usually is. The more important question is where this profile should live.

The traditional model: the CDP as the center

Traditional CDPs solve the problem by creating a specialized platform with its own storage, data model, identity resolution logic, segmentation engine, and activation connectors.

The architecture is roughly this:

Sources → CDP database → Customer profiles / segments → Destinations

This model made a lot of sense, especially when many companies did not have a mature data warehouse or a data team able to build and maintain this infrastructure internally. A traditional CDP gave marketing and growth teams a ready-made environment to collect events, unify identities, build audiences, and push data to other tools without waiting months for a custom data platform.

This is worth saying clearly: traditional CDPs solved a real problem. They made customer data operational, not just analytical. They gave non-technical teams a way to work with data that would otherwise have stayed trapped in databases, logs, exports, or tickets in the data team backlog.

The trade-off is architectural. A traditional CDP often becomes another place where customer data lives. Data is copied from source systems into the CDP. The CDP builds its own representation of the customer. That representation may then coexist with another one in the data warehouse, another one in the CRM, and several partial versions in downstream tools.

That can work, but it introduces familiar problems: duplication, synchronization logic, possible inconsistencies, vendor lock-in, and governance that is split across multiple systems. If the CDP says a customer is “active” and the warehouse says they are “at risk,” which one is correct? If an AI workflow uses a customer profile, which version should it use?

These are not just philosophical questions. They become practical as soon as customer data starts driving automated decisions.

Why warehouse-first changed the conversation

Warehouse-first comes from a different context.

In many companies today, the data warehouse is no longer just a place for dashboards and monthly reports. It is where product events, CRM data, billing data, support data, marketing data, and finance data are combined. Whether the stack is built on Snowflake, BigQuery, Redshift, Databricks, or something else, the warehouse is often the closest thing the company has to a governed data foundation.

At that point, the CDP conversation changes. If the warehouse is already where the company combines and governs its data, it is reasonable to ask why the canonical customer profile should live somewhere else.

A warehouse-first CDP starts from this premise. Instead of treating the CDP vendor’s database as the center, it treats the customer’s warehouse as the center.

The architecture becomes closer to this:

Sources → Customer warehouse → Customer profiles / segments → Destinations

The CDP still has a job to do. It may handle ingestion, identity resolution, profile building, audience management, reverse ETL, or user-facing workflows. But the key difference is that the profile is built in the customer’s data environment, not inside a proprietary external silo.

For developers and data teams, this is the part that matters. The warehouse is queryable. It can be inspected. Models can be versioned. Lineage can be understood. Access control can follow existing policies. Profiles and segments can be reused by analytics, product, finance, customer success, and AI workflows, not only by marketing tools.

Warehouse-first is not always better, but it aligns the CDP with the place where many companies already manage their most important data assets.

Warehouse-first is not one architecture

Part of the confusion is that “warehouse-first CDP” is not a single architecture. It is a family of approaches.

Some tools are mostly read-in-place. They connect to tables that already exist in the warehouse, let users define audiences or mappings, and materialize only the outputs needed for activation.

Some tools are closer to reverse ETL platforms. They assume the warehouse already contains clean customer tables, traits, and segments, and focus on syncing those records to SaaS applications like Salesforce, HubSpot, Braze, Customer.io, Intercom, or advertising platforms.

Other systems take a more managed approach. They collect events, import identities and attributes from SaaS tools, and normalize everything into a canonical CDP schema inside the customer’s warehouse. On top of that schema, they perform identity resolution, build unified profiles, and activate those profiles back to downstream systems.

That last model matters because it sits between a pure “bring your own modeled tables” approach and a traditional CDP. It does create normalized tables, and in some cases that means duplicating data that was already present in the warehouse. But the copy lives in the customer’s warehouse, follows a schema the customer can inspect and control, and becomes part of the company’s own data architecture rather than a black box owned by the CDP vendor.

That is a small architectural detail with a large practical impact.

Duplication is not the real issue

Warehouse-first CDPs are often described as a way to avoid data duplication. That is directionally true compared with a traditional CDP that stores another customer database outside the warehouse, but it can also be misleading.

Some duplication is unavoidable. If customer data lives in SaaS tools, and you want to combine it with product usage, billing, support, and marketing data, you usually need to copy it into a common environment. If data already exists in the warehouse, it may still be useful to normalize it into a common schema for identity resolution, profile building, and activation.

So the real distinction is not “duplication or no duplication.” The better distinction is: who controls the duplication, where does it happen, and what purpose does it serve?

In a traditional CDP, the normalized customer profile often lives in the vendor’s platform. In a warehouse-first model, any necessary materialization happens in the customer’s warehouse. That does not eliminate every copy, but it avoids creating a separate proprietary customer data silo.

For a technical audience, this is the more honest way to frame it. Warehouse-first is not magic. It is an architectural choice. It says that if customer profiles, identities, and segments are strategic data assets, they should be built where the company can query them, govern them, reuse them, and move away from a vendor without losing the foundation of its customer data work.

AI raises the stakes

AI makes this discussion harder to ignore because it puts more pressure on the quality and consistency of customer context.

If AI systems are going to summarize accounts, suggest actions, personalize messages, classify users, detect churn risk, or update CRM records, they need customer context. That context cannot be a random mix of stale attributes, conflicting identifiers, and partial records from disconnected tools.

A traditional CDP can support AI use cases too. That is not the issue. But the warehouse-first model is often a more natural fit when AI needs cross-functional context: product usage, revenue, support, lifecycle, consent, account hierarchy, and operational history. Those signals often already exist, or should exist, in the warehouse.

In that sense, AI does not replace the need for a CDP. It raises the bar for what the underlying customer data layer needs to provide.

A CDP is an architecture decision

The comparison between traditional CDPs and warehouse-first CDPs is sometimes framed as a feature comparison: connectors, audience builder, real-time events, identity resolution, reverse ETL, and so on. Those features matter, but they are not the decision that shapes the architecture.

The core issue is where the customer profile should live. A traditional CDP builds it inside the CDP platform and activates it from there; a warehouse-first CDP builds it in the customer’s warehouse and uses the CDP layer to make it operational.

Both approaches can be valid, depending on the company’s maturity, team structure, use cases, and urgency. A marketing team without a mature data warehouse may get value from a traditional CDP faster. A company with a strong warehouse, a data team, and broader use cases across product, sales, customer success, and AI may prefer to keep the customer profile closer to its existing data foundation.

That trade-off should be explicit from the start. A CDP is not only a tool for sending audiences to other tools. It is a decision about the architecture of customer data.

Once customer data starts feeding automation and AI, that decision is no longer just an implementation detail.

This article was originally published on the Krenalis blog.

At Krenalis, we are building a warehouse-first CDP around the same idea: customer profiles should live in the company's own data environment, not in another proprietary silo.

You can learn more about our approach on the Krenalis website.

If the warehouse already has the data, why are we copying it elsewhere?

Marco Gazerro — Fri, 05 Jun 2026 09:10:49 +0000

When we started working on Krenalis, we spent a lot of time reviewing how customer data typically flows through a modern data stack.

One pattern kept showing up often enough that we started questioning it.

In many modern stacks, customer data already lands in a warehouse. Yet we often copy that same data into a CDP before we can start building customer profiles.

During one of those discussions, someone asked a question that sounded almost naive:

Why are we moving all this data in the first place?

Nobody had a particularly strong answer ready. The answer was mostly:

Because that's how CDPs work.

We expected the question to have an obvious answer. It didn't.

The warehouse is no longer just for analytics

Over the last few years, the role of the data warehouse has changed significantly. Warehouses are no longer just analytical systems. They're increasingly becoming the place where organizations centralize the context used by applications, AI agents, copilots, and business processes.

Customer data from systems like Shopify, Stripe, CRMs, support platforms, and internal applications often ends up there long before anyone starts thinking about segmentation or activation. In many organizations, the warehouse is already the place where teams answer questions about customers, revenue, retention, and product usage.

That made us wonder:

If the warehouse is already becoming the operational center of the data stack, why does customer identity usually live somewhere else?

Consider a customer who buys through Shopify, pays through Stripe, opens support tickets in Zendesk, and uses the product under a different email address. In many organizations, all of those records already end up in the warehouse. Yet building a unified profile often requires exporting that same data into another platform before identity can be resolved.

The cost of another copy

To be clear, data duplication is not inherently bad. Most software systems rely on some form of replication, caching, or denormalization.

The question is whether an additional copy is actually necessary.

When customer data exists across multiple platforms, a few familiar challenges tend to appear. Sooner or later, two systems report different numbers and someone has to determine which one is correct. As customer profiles become the result of multiple pipelines and transformations, understanding exactly how a profile was built becomes more difficult. Additional systems also introduce additional integrations, monitoring requirements, and opportunities for data drift.

None of these problems are unique to CDPs. They're simply common side effects of moving data between systems.

A different perspective

At some point we stopped asking:

How should we move data into the CDP?

and started asking:

What if we didn't?

Once we started looking at the problem from that angle, a warehouse-native architecture felt like the obvious thing to explore.

Instead of bringing customer data into the CDP, we started exploring what would happen if identity resolution, profile generation, and audience segmentation happened directly on top of the data that was already in the warehouse.

The underlying idea can be summarized in a simple sentence:

The CDP doesn't need to own the data. It only needs to understand it.

Whether that idea ultimately proves right or wrong is a different question. What mattered to us was that it seemed increasingly aligned with the direction the rest of the modern data stack was already taking.

Why this question feels relevant today

The idea behind Krenalis didn't emerge in isolation.

By the time we started working on it, many parts of the modern data stack had already moved closer to the warehouse. Analytics increasingly treats it as the source of truth, transformations often run there, and business logic is frequently built around it. More recently, AI applications and agent workflows have started using it as a source of context as well.

The trend itself wasn't particularly surprising. What caught our attention was the question that followed from it.

If so much of the modern data stack is converging around the warehouse, what does that mean for customer identity?

If customer events, transactions, support interactions, business metrics, and AI context are already stored in the warehouse, resolving customer identity there starts to feel less like a technical compromise and more like a natural extension of the same idea.

One aspect of this approach that we find particularly compelling is transparency. Customer identity becomes something that can be inspected, queried, and reasoned about using the same tools teams already use for the rest of their data.

Instead of treating identity as something produced by a separate platform, it becomes part of the data model itself.

There may still be good reasons to keep customer identity inside a dedicated system. Dedicated platforms can provide a better user experience, faster onboarding, and a simpler path for teams that don't want to operate directly on warehouse data.

But the more central the warehouse becomes, the more natural it feels to ask whether identity resolution should happen there too.

The trade-offs are real

Warehouse-native isn't a universal answer.

If a team doesn't already rely heavily on a data warehouse, introducing warehouse-native tooling may create more complexity than it removes. Likewise, if the primary goal is to launch campaigns quickly with minimal involvement from data teams, a traditional CDP may be a better fit.

A warehouse-native architecture also doesn't solve data quality problems. If customer data is incomplete, inconsistent, or fragmented, those issues remain. In fact, they often become more visible.

Depending on your perspective, that's either a benefit or an inconvenience.

A bet on where things might be heading

We're not arguing that every CDP should become warehouse-native.

Traditional CDPs solve real problems and continue to provide value for many organizations.

What interests us is a broader question. As warehouses become the foundation for analytics, business operations, AI applications, and agent workflows, will customer identity eventually follow the same path?

We think there is a strong case for that direction, especially in composable architectures where the warehouse is already the place where customer context is modeled, governed, and used.

Maybe this becomes the default model for some teams.

Maybe it remains one architectural option among many.

We kept coming back to that question, and eventually decided it was worth building around.

And it's one of the reasons Krenalis exists.

What do you think?

If you've worked on CDPs, customer identity, or warehouse-native architectures, we'd genuinely love to hear about your experience.

Leave a comment below or drop us a note at hello@krenalis.com.

For anyone interested in how we're approaching these problems, we've made the project repository available here:

https://github.com/krenalis/krenalis