The Composable CDP: How Customer Data Stopped Moving

When a foundational identity-and-connectivity rail gets acquired and absorbed, every team that quietly depended on it has to answer the same question: what do we rebuild, and where does it now live?

The honest answer is that you do not rebuild the old stack. You rebuild a different one — and the most consequential change is not which vendor you swap in, but a decision about whether your customer data moves at all.

For two decades the unspoken default was that data moves. It moved from your systems into a platform, from that platform into a second platform, and from there into the tools that actually did the work. Every hop was a copy. Every copy was a cost, a liability, and a small surrender of control. The category emerging now is defined by refusing that default.

It helps to see the modern stack in three layers — connectivity at the top (the walled gardens, measurement systems, and programmatic platforms where activation actually lands), identity at the bottom (graphs, cross-device resolution, universal IDs), and the data layer in the middle, where management and collaboration happen. The interesting action is in that middle layer, and the interesting move is architectural: rebuild the data layer so the source of truth never leaves the warehouse you already own.

That move has a name. It is the Composable CDP, and it is best understood not as a product but as the third generation in a lineage.

Naming the negation

David Raab coined the term Customer Data Platform in April 2013. The canonical definition that followed — packaged software that creates a persistent, unified customer database accessible to other systems — contains the word that the next generation set out to destroy: packaged.

A Composable CDP is an architectural pattern, not a single bundled application. Instead of buying one system that collects, stores, unifies, and activates customer data, you assemble interchangeable best-of-breed components for each stage on top of a cloud data warehouse you already operate. Its defining property is warehouse-native and zero-copy: the unified profile lives in the warehouse — Snowflake, BigQuery, Redshift, Databricks — and is read in place rather than ingested into a vendor-owned store. Profiles, segments, scores, and activation logs are computed and written back inside the warehouse, governed by your own security and access controls.

The category is defined by what it refuses to do, not by a feature it adds: the word “packaged” is exactly what “composable” set out to negate.

The framing itself was borrowed. Composable arrived from Gartner’s composable-enterprise and Packaged Business Capabilities constructs around 2020 — the idea of building systems from interchangeable, API-bounded parts. The application to customer data emerged when data teams noticed something obvious in hindsight: their first-party data was already centralized in a cloud warehouse, which made a second proprietary copy inside a packaged CDP redundant. The enabling mechanism — reverse ETL — was popularized by activation vendors around the same time.

Three generations, three problems

The lineage is a record of successive problem-solving, not fashion. Each generation fixed its predecessor’s core failure and inherited a new one.

The first generation was the data management platform. DMPs solved cross-site audience scale for advertising by aggregating anonymous third-party-cookie data into short-lived segments. What they never had was persistent identity or genuine first-party profiles — and as third-party cookies decayed and privacy regulation tightened, that gap hollowed out the core. The economics that once made addressable audiences a hundred-billion-dollar question shifted underneath them.

The second generation, the packaged CDP, solved the identity problem directly: persistent, identity-resolved, known-customer profiles in a single vendor-managed application. In practice it is the layer where a brand maps a foundational identity graph and powers psychographic and behavioral personalization. But it solved identity by duplicating customer data — including PII — into a proprietary store, which brought vendor lock-in, high fixed cost, long implementations, and, repeatedly, disappointing realized value.

The third generation removed the duplication and the lock-in by leaving the data in the warehouse and paying per component. Its new trade-offs are real: multi-vendor integration complexity, a buyer shift toward data engineering, and replication latency that can blunt real-time loops.

Each generation fixed its predecessor’s core failure — and introduced a new one. The lineage is a ladder of trade-offs, not a verdict.

The disappointment that created a category

A category defined by negation needs proof that the thing it negates fell short. That proof exists. By the measures the analyst community tracks, only about 58% of CDP deployments delivered significant value; 30–50% of CDP projects miss their first-year value target; and Gartner’s 2025 Magic Quadrant found only about 22% of marketers reporting high business-user utilization — alongside persistent concern about PII duplication.

This is a demand-side origin story, not a technology push. Composable did not win because warehouses got a clever new feature. It won because the bundled promise underdelivered often enough that buyers went looking for an architecture that asked them to copy less and own more.

No data egress: the architecture and its economics

The defining property of the warehouse-native model is simple to state and consequential to enforce: no customer data is persisted outside your own cloud warehouse. Profiles, segments, scores, and activation logs are computed and written back in place. Because the guarantee is enforced by your own security and access controls rather than a vendor’s promise, governance becomes a property of the architecture.

The economic argument is not rhetorical. It is grounded in real cloud egress pricing. Moving data in costs nothing; same-region transfer costs nothing; cross-region transfer within a cloud runs on the order of $20/TB; and cross-cloud or internet egress runs roughly $87.50–$230/TB depending on provider and region. The packaged model pays a version of that tax repeatedly — once to copy data into the CDP, and again to copy it into each activation tool. The zero-copy model pays it never for the profile itself; it transmits only the resolved segment.

Keeping data in place is free; moving it out is metered. The packaged model pays that tax once per copy. Zero-copy pays it never.

Governance compounds the case, and it connects directly to why portability and interoperability matter. Every copy of customer data is a new attack surface, a new place to enforce consent, and a new target for a deletion request. Keep one governed copy and you enforce access controls, audit trails, residency rules, and the right to be forgotten once — instead of chasing the same record across five vendor systems.

Each copy of customer data is a new attack surface, a new place to enforce consent, and a new target for a deletion request.

Structural, not incidental

The contrast with the ingest-and-store CDP is structural, not a matter of degree. A bundled CDP ingests, stores, and activates inside one proprietary system, which forces an organization into an awkward choice: is the source of truth for customer data the CDP, or the warehouse? Answering “the CDP” fragments the truth and creates a second silo outside the modern data stack — business logic re-implemented inside a black box.

The composable approach refuses the choice. It reuses warehouse-resident infrastructure — the same dbt-defined metrics analytics already trusts — so the logic is not rebuilt in a place no one can audit. And the deeper enabler of collaboration is no-copy data sharing: the warehouse grants a read-only reference through its metadata and services layer rather than transferring bytes. Shared data consumes zero storage in the consumer’s account, access is near-instantaneous, and the consumer pays only for the compute used to query it.

Reverse ETL: the last mile

If the warehouse is the source of truth, something has to carry the truth to the tools where people actually work. That something is reverse ETL — and it earns its place as the activation layer by inverting a fifty-year-old pattern.

Classic ETL (IBM, 1970s) extracts from source systems, transforms on a separate engine, and loads into the warehouse. ELT (cloud warehouses, roughly 2012 onward) loads raw data first and transforms in place. Both end in the warehouse, writing schemas you own. Reverse ETL runs the pipeline the other direction: it syncs cleaned, modeled data out of the warehouse and into the operational SaaS tools business teams live in — CRMs, ad platforms, email systems, support desks — making warehouse data actionable without anyone writing SQL or living in a dashboard.

The mechanism is unglamorous and exact. A scheduled or event-triggered query runs against modeled tables; because warehouses cannot emit change-data-capture logs for arbitrary SQL, the tool diffs the current result set against a snapshot of the prior run to find what changed, maps fields to each destination’s schema, and writes only the changed rows to each destination’s API. Cadence spans event-driven sub-minute syncs, five-to-fifteen-minute polling, and hourly or daily batch. Unlike ETL and ELT — which write to schemas you control — reverse ETL must conform to third-party destination APIs, which makes it genuinely harder to engineer per destination.

Reverse ETL is what turns data infrastructure you already pay for into a composable CDP.

The term, notably, was named rather than invented. The category emerged around 2018 and went mainstream by 2021, driven by activation vendors describing themselves as pushing data out of the warehouse. No single person formally coined it; it was a category-naming event.

What reverse ETL is not

Discipline about the boundary is what keeps the whole thesis honest. Reverse ETL is one component of a CDP, not a substitute for one. It does not collect events — there is no SDK, no event stream. It does not resolve anonymous-to-known identity. It does not serve sub-second profile lookups, native messaging, or AI decisioning. It operates strictly downstream of collection, assumes a unified customer table already exists, and activates pre-built segments on a batch-to-near-real-time schedule.

Reverse ETL is one component of a CDP, not a substitute for one — it activates a unified table it assumes already exists.

If you arrived here weighing the two head-to-head, the comparison has its own page: CDP vs. Reverse ETL Is the Wrong Question — the decision table, the three scenarios, and the trap on each side.

That boundary also names the model’s honest cost: latency. Historically, batch reverse-ETL syncs have trailed packaged CDPs on real-time personalization. The no-egress model’s real trade-off is not capability, it is freshness — which is why hybrid patterns that pair warehouse-native ownership with a real-time path keep appearing.

Multi-cloud clean rooms: collaboration without the copy

No-copy sharing does not stop at the edge of one organization. The same primitive — reference, not copy — is exactly what clean rooms generalize across companies, letting parties collaborate on customer data without moving it. It is the natural endpoint of the zero-party and cookieless trajectory.

The architecture has matured in a specific way. The rigid 1:1 provider/consumer model — where every pair of participants needs its own room, so rooms multiply with the square of the partner count — is giving way to a symmetric, multiparty design driven by a collaboration API. An owner assigns flexible roles (owner, data provider, analysis runner); any party can contribute data, submit query templates, and specify per-template access. The result is that an ecosystem can scale to dozens of partners without combinatorial room sprawl, on the same “reference, not copy” foundation.

Positioned in the lineage, this is the collaboration layer of the warehouse-native stack — sitting beside reverse ETL, which is the activation layer. The warehouse vendor owns the privacy-safe join; the composable layer owns resolution and activation. That division of labor matters: it makes the activation layer an interoperability beneficiary, not a competitor to the clean room it reaches into.

But isn’t that just a clean room?

This is the question that trips everyone up — fairly, because from a distance the two look almost identical. Both keep data in place. Both talk about “collaborating without copying.” Both increasingly run on the very same warehouses. So where is the line?

The line is the verb. A clean room is a privacy-safe compute environment: its job is to run an approved join across two or more parties’ data so that neither side ever sees the other’s raw rows. A composable CDP is an activation layer: its job is to sync one party’s resolved data out to the operational tools that act on it. One computes a result; the other delivers a segment.

The cleanest test is to ask who is being protected from whom:

• A clean room protects two parties from each other — the brand cannot see the publisher’s user-level rows, and vice versa. It exists precisely because there is a counterparty.
• A composable CDP has no counterparty to hide from. The thing it guards against is unnecessary copies of your own data. It is a single-player governance story, not a two-player one.

Which is exactly why they are complementary, not competing — they are a relay:

1. The clean room answers “who can we reach together, safely?” — a brand and a publisher compute a privacy-safe overlap and produce an approved, matched audience, with no raw PII ever exposed.
2. The composable CDP answers “now go reach them” — it takes that approved audience (or your own first-party profile) and activates it: a sync to the DSP, the CRM, the email platform.

A clean room without an activation layer leaves the approved audience stranded in the room; a composable CDP without a clean room cannot lawfully combine two parties’ data in the first place. Each is the other’s missing half.

So why the constant conflation? Because the modern warehouse now offers both — a clean-room capability and the home for the composable CDP’s data — on one platform. The same vendor sells you the governed join and the activation tooling stacked on top of it. But they remain different functions even under one roof: one is where the privacy-safe match happens; the other is what carries the result to the place it does work. Same building, different floors.

Or just rent an identity spine?

The other thing the composable model gets confused with sits one layer beneath activation: the identity-and-connectivity utility. You onboard your data to a third party, it resolves that data to a shared, industry-wide ID, and syndicates it out across the open ecosystem. Call it identity-infrastructure-as-a-service — you rent a neutral spine and the rails that ride on it.

That is different in kind, not degree. Its whole proposition is reach: a shared ID that publishers, platforms, and partners all speak, so your audience can be matched and activated almost anywhere. You pay for that reach with a dependency on a third party — and, historically, with copies of your data into its environment.

The warehouse-native model makes the inverse bet: own the substrate instead of renting the spine. Identity is resolved inside your own warehouse and governance — your keys, your match logic, or a clean-room join with a named partner — with no third-party spine sitting in the middle of your first-party data.

The honest nuance holds here too: it is not purely either/or. A warehouse-native stack still usually bridges to a shared ID at the activation edge — a universal ID, or a clean-room match — because your internal keys do not reach the open web on their own. What changes is posture: the shared spine becomes a component you call for reach, not the system of record you depend on.

And this is where the opening of this essay stops being abstract. The case for owning the substrate sharpened the moment the industry’s most-used neutral spine stopped being neutral. In May 2026, Publicis agreed to acquire LiveRamp — the dominant identity-resolution-and-connectivity layer — in an all-cash deal valued at roughly $2.5 billion, expected to close by the end of 2026. The stated logic was data and “agentic” capability for the AI era.

But neutrality was the entire value of a spine everyone routed through. The day an agency holding company owns the rails your first-party data and identity travel on, every rival holding company — and every brand wary of feeding a competitor — gains a concrete reason to stop depending on the spine and rebuild the data layer they control. The deal does not end the utility model; it turns “own your own substrate” from a governance preference into a competitive one. (The quiet irony: the utility had already moved warehouse-native and into clean rooms — migrating toward the very architecture its acquisition now accelerates.)

The lock-in swap: where the weight actually went

Here is the critique the category’s marketing tends to skip, and the most important thing to put on a stack diagram honestly. Composable does not escape lock-in. It relocates it.

The packaged era concentrated lock-in at the application layer: your customer data sat inside one vendor’s black box. The composable era dissolves that — thin, swappable tools for identity, segmentation, and reverse-ETL activation bolt onto infrastructure you own. But the dependency does not vanish; it migrates to the one component that is hardest to leave. The warehouse becomes the single point of concentration for storage, the identity graph, compute, and the SQL dialect every pipeline is written against — the highest-switching-cost layer in the stack. If warehouse compute pricing moves, the economics of the entire activation layer move with it.

And the no-egress governance win has a quiet asterisk: the activation layer’s reverse-ETL syncs still write copies to each destination by design. So while the profile stays in one governed place, the activation surface multiplies with vendor count — scaling data-processing agreements, audit scope, breach vectors, and deletion complexity right back up.

Composable reduces application-layer lock-in while concentrating, and arguably deepening, the dependency on the one component hardest to leave: the warehouse.

None of this is a reason to reject the architecture. It is the cost of the architecture, stated plainly — which is the only way to choose it well.

The activation layer becomes the agent’s execution surface

There is a forward edge to all of this, and it is where the warehouse-native stack stops being a data-engineering story and becomes an agentic one.

Once the unified profile lives in the warehouse and reverse ETL is the path to action, the activation layer becomes the obvious execution surface for advertising agents. Natural-language configuration already lets non-engineers define audiences and integrations; autonomous decisioning is moving from a feature into the product thesis. An agent that can read a governed profile in place, resolve identity inside the customer’s own controls, and activate through a standard reverse-ETL path does not need a bespoke integration for every destination — it needs a protocol. That is precisely the gap that emerging agentic standards aim to fill, and it is why containerizing the signal — packaging intent, provenance, policy, and activation logic into one portable, governed object — is the natural unit of work for this layer.

The enterprise-data world is arriving at the same edge from the other direction. A 2026 Databricks executive publication makes the case to CIOs that a governed data layer is no longer only the foundation for analytics — it is the foundation for agents, and its sharpest framing is a governance one: an agent is like a data asset. It costs money continuously, it has a threat surface, and — the line that belongs on every activation-layer roadmap — “you cannot turn off what you cannot see.” Whatever discipline a warehouse-native stack already applies to the profile — lineage, access, expiry, observability — is the discipline an agentic activation layer will have to apply to the agents acting through it. That is the quiet compounding advantage of stopping the data from moving: the governance you built for the profile becomes the governance you need for the agent, and the same catalog that resolves which copy of the customer table is current also resolves which slice of the warehouse an agent may reason from — the yardstick shifting, as it does everywhere agents touch money, from how many you deployed to whether you can govern, audit, and retire them.

The throughline of three generations finally resolves here. The DMP moved anonymous audiences. The packaged CDP moved known profiles into a box. The composable generation stopped moving the data at all — and in doing so, turned the warehouse from a place you analyze the past into the surface where agents act on the present.

That is the real shift. Not a better segment, not a cheaper license. Customer data stopped moving, and the work came to it.

Where the work goes next is the sequels’ territory: one governed memory absorbing the paid/owned wall, and — because the profile the warehouse governs carries the who and the what of a customer’s moment but not its where or when — the context economy.