Composable CDP vs Reverse ETL vs Packaged CDP.
What actually moves, where it lives at rest, and where identity resolves — the decision table for a comparison the category blurred on purpose.
A packaged CDP is a suite that bundles collection, identity resolution, segmentation, and activation on its own copy of your customer data. A composable CDP is an architectural pattern that keeps the profile in your cloud warehouse and reads it in place. Reverse ETL is a pipe that syncs modeled data out of that warehouse into operational tools — the activation layer of a warehouse-native stack, and nothing else. This page compares all three on the dimensions that decide purchases.
This is not a bake-off, because these are not three of the same thing: one is a suite, one is an architecture, one is a pipe. Answer one question — where should the governed copy of your customer live? — and the comparison resolves itself.
Fast read
- What it is
- A decision table for the three architectures buyers keep comparing head-to-head: the packaged CDP (a suite), the composable CDP (an architectural pattern on your warehouse), and reverse ETL (a pipe).
- The category error
- A CDP is a suite — a place customer data lives, plus the machinery around it. Reverse ETL is a pipe — it moves modeled data out of the warehouse and does nothing else. One is a noun; the other is a verb.
- What actually moves
- Packaged: your events and PII are copied into the vendor’s store, then again into each activation tool. Composable: the profile is read in place; only the resolved segment transmits. Reverse ETL: changed rows only, diffed against the prior run.
- Where identity resolves
- Packaged: inside the vendor’s application, on vendor logic. Composable: inside your warehouse — your keys, your match logic, or a clean-room join. Reverse ETL: nowhere — it moves rows that are already resolved upstream.
- Watch-out
- Buying reverse ETL and calling it a CDP is the most expensive version of this confusion. Collection, identity, and modeling do not arrive in the box — teams discover that at integration time.
- Best next read
- The two narrative essays this table condenses: "CDP vs. Reverse ETL Is the Wrong Question" and "The Composable CDP: How Customer Data Stopped Moving."
The decision table.
Three architectures across the eight dimensions that decide purchases. Every row condenses the two narrative versions of this argument — CDP vs. Reverse ETL Is the Wrong Question and The Composable CDP: How Customer Data Stopped Moving — into table form. Last validated 2026-08-03. Read the last three rows twice: they decide more purchases than the first five.
| Dimension | Packaged CDP | Composable CDP | Reverse ETL |
|---|---|---|---|
| What data actually moves | Your events and PII are copied into the vendor’s store, then copied again into each activation tool. Every hop is a copy. | The profile does not move. It is read in place in your warehouse; only the resolved segment transmits at activation. | Changed rows only: a scheduled or event-triggered query, a diff against a snapshot of the prior run, and writes of what changed to each destination’s API. |
| Where the customer copy lives at rest | The vendor’s infrastructure, on the vendor’s schema, priced by the vendor’s meter. | Your warehouse — Snowflake, BigQuery, Redshift, Databricks — on your schema, under your own security and access controls. | Nowhere of its own. It assumes your customer truth already lives in a warehouse: modeled, deduplicated, governed. |
| Where identity resolves | Inside the vendor’s application: anonymous-to-known stitching, vendor logic. | Inside your warehouse and governance: your keys, your match logic, or a clean-room join with a named partner — no third-party spine in the middle of your first-party data. | It does not resolve identity. No SDK, no event stream, no stitching — it moves rows that were resolved upstream. |
| Activation path | The vendor’s integration catalog, often with real-time personalization APIs on top. | Reverse ETL as the last mile: destination APIs, engineered per tool. Batch to near-real-time; sub-second is not the native mode. | It is the activation layer: field mapping to each destination’s schema, cadences from event-driven sub-minute syncs to five-to-fifteen-minute polling to hourly or daily batch. |
| What breaks or duplicates | PII duplicated into a proprietary store — every copy is a new attack surface, a new place to enforce consent, a new target for a deletion request. A second silo, with business logic re-implemented inside a black box. | Freshness: batch syncs have historically trailed packaged CDPs on real-time personalization. And activation syncs still write copies to each destination, so the activation surface multiplies with vendor count. | The trap is buying it alone and calling it a CDP. Collection, identity, and modeling do not arrive in the box — discovered at integration time, the most expensive place to discover anything. |
| Who owns the schema | The vendor. After three years of accreted segments and integrations, that is where the switching cost lives. | You — the same dbt-defined models analytics already trusts, so the logic is not rebuilt in a place no one can audit. | The source schema is yours; the target schema belongs to each destination’s API — which is what makes reverse ETL genuinely harder to engineer per destination. |
| Cost shape | Platform fee, often volume-priced — and the egress tax paid once per copy (cross-cloud or internet egress runs roughly $87.50–$230/TB; cross-region within a cloud on the order of $20/TB). | Warehouse compute plus per-destination sync. Zero-copy pays the egress tax never for the profile itself. The lock-in does not vanish; it relocates to the warehouse. | Priced inside the composable stack: per-destination sync on data infrastructure you already pay for. |
| When it wins | You do not have a disciplined warehouse — no modeled customer tables, no data team with time for marketing. Then packaged is not a compromise; it is the correct tool. | Your warehouse is already the source of truth. A second proprietary copy is then redundant by construction. | Always as the last mile of a warehouse-native stack — never as a CDP substitute. |
Why the categories blurred
The confusion is commercial, not conceptual: reverse-ETL companies rebranded as "composable CDPs" and packaged CDPs quietly bolted on warehouse connectors. The category blurred itself for commercial reasons, and buyers inherited the blur. The disappointment that created the composable category is documented too — 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.
Where identity resolves.
Identity resolution — turning anonymous and fragmented records into a persistent, known-customer profile — is the job that most cleanly separates the three architectures, because each one performs it in a different place, under different ownership. Two mechanics recur everywhere: deterministic resolution matches records on exact shared keys (a login, a hashed email), and probabilistic resolution infers likely matches from weaker signals with a confidence score. Which mechanics a system uses is a product question; where it runs them is the architecture question this section answers.
- 01
Packaged CDP: the managed graph
Identity resolution is included in the bundle and runs inside the vendor’s application — anonymous-to-known stitching on the vendor’s logic, against the vendor’s copy of your data. You buy the job done; you accept that the match logic, like the schema, is the vendor’s.
- 02
Composable CDP: in-warehouse
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. Resolution output is written back in place and governed by the same access controls as everything else.
- 03
Reverse ETL: already resolved
Reverse ETL performs no resolution at all. It operates strictly downstream of collection and identity, and syncs rows from a unified table it assumes already exists. If identity is unresolved in the warehouse, the pipe faithfully delivers unresolved rows.
The bridge caveat
Owning resolution in-warehouse does not remove the need for shared identity everywhere: internal keys do not reach the open web on their own. A warehouse-native stack still usually bridges to a universal ID or a clean-room match at the activation edge — the difference is that the shared spine becomes a component you call for reach, not the system of record you depend on. Rent the spine, or own the substrate: that is the identity-utility trade in one line.
The shared graphs, defined
Two terms arrive with this comparison and deserve neutral definitions. The LiveRamp identity graph is the best-known third-party spine: a shared graph of persistent, people-based identifiers used to match and connect records across partners, clouds, and clean rooms — optimized for reach, paid for with dependency (in May 2026, Publicis agreed to acquire LiveRamp for roughly $2.5 billion in cash, expected to close by end of 2026). The DMP is the identity architecture the CDP generations replaced: it aggregated anonymous third-party-cookie data into short-lived segments and never held persistent identity or genuine first-party profiles — which is why "first-party data in a DMP" was always a strained fit, and why the first-party question moved to the CDP. Both terms are defined in the glossary; the DMP story is told in full in The DMP and Programmatic.
Which architecture, by constraint.
The deciding question is not feature coverage. It is: where should the governed copy of your customer live? Answer it from your actual constraint — warehouse discipline, team shape, freshness requirement — and the architecture follows.
- 01
No disciplined warehouse
No modeled customer tables, no data team with time for marketing. The packaged CDP is not a compromise; it is the correct tool. You are buying all four jobs done, and the price of the vendor’s copy is lower than the price of pretending you have infrastructure you don’t.
- 02
Warehouse is already the source of truth
Modeled, deduplicated, governed. A second proprietary copy inside a packaged CDP is redundant by construction, and reverse ETL is your activation last mile. That is the composable thesis in one sentence.
- 03
You need both truths
Warehouse ownership and sub-second personalization. That is the honest hybrid: a warehouse-native core with a real-time path bolted on where freshness pays. The original call here — expect to engineer the seam yourself, because nobody sells it clean — lasted eight days: Snowflake now sells exactly that seam as a governed warehouse-to-platform loop, and the correction is on the record. The question to ask a vendor is no longer whether the seam is sold; it is whose governance it runs under.
The trap on each side
Composable side: buying reverse ETL and calling it a CDP — a delivery truck declared a warehouse district. Packaged side: paying a platform fee to maintain a second copy of data your warehouse already governs, then paying again in switching costs when three years of segments, integrations, and vendor schema have accreted. The data was never locked in; everything around it was. And composable does not escape lock-in either — it relocates it to the warehouse, the highest-switching-cost layer in the stack. That is the cost of the architecture, stated plainly, which is the only way to choose it well.
The agentic postscript
Agents are becoming the primary readers of customer data, and an agent needs a governed truth to act on — memory, permissions, and audit live wherever the customer copy lives. That strengthens the warehouse-native case for anyone who can operate it, and raises the packaged exit stakes: not just your segments in the vendor's copy, but your agents' institutional memory. The fourth-generation products making this argument are early — much of it is vendor-claimed and architecturally reasoned rather than operationally demonstrated. The full argument is in the agentic CDP essay.
A suite versus a pipe — stop comparing, start deciding.
The "vs" framing survives because it sells: both sides marketed across the boundary until the boundary disappeared. But nobody who has answered the governed-copy question still needs the comparison. If your warehouse is disciplined, composable plus reverse ETL is your architecture and the packaged CDP is a redundant copy. If it is not, the packaged CDP is the correct tool and no amount of pipe-buying will change that. The comparison dissolves — usually along with the search query that brought you here.
Frequently asked questions.
What is the difference between a CDP and reverse ETL?
A CDP is a suite: a place customer data lives, plus event collection, identity resolution, audience definition, and activation around it. Reverse ETL is a pipe: it syncs modeled data out of a cloud warehouse into operational tools — CRMs, ad platforms, email systems — and does nothing else. Comparing them head-to-head is a category error; reverse ETL is one component of a CDP, not a substitute for one, and it activates a unified customer table it assumes already exists.
Where does identity resolution happen in a composable CDP?
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 resolved profile is read in place rather than copied into a vendor store. One caveat: internal keys do not reach the open web on their own, so warehouse-native stacks still usually bridge to a shared ID or clean-room match at the activation edge — the shared spine becomes a component you call for reach, not the system of record you depend on.
Is a composable CDP just reverse ETL with a new name?
No. Reverse ETL is the activation layer of a composable CDP — the last mile — but collection, identity resolution, and modeling are separate components on top of the warehouse. Buying reverse ETL and calling it a CDP is the composable-side trap: no SDK, no event stream, no identity stitching, and no sub-second lookups arrive in the box, and teams discover that at integration time.
Do packaged CDPs use deterministic identity resolution?
Packaged CDPs perform identity resolution inside the vendor’s application, on the vendor’s logic. Deterministic resolution matches records on exact shared keys — a login, a hashed email; probabilistic resolution infers likely matches from weaker signals with a confidence score. Products differ in how they combine the two, and the mix is a vendor product decision, not a property of the category — ask for the match logic in writing rather than assuming it from the label.
When does a packaged CDP beat a composable CDP?
When you do not have a disciplined warehouse: no modeled customer tables and no data team with time for marketing. In that situation the packaged CDP is the correct tool — you are buying collection, identity, segmentation, and activation done, and the price of the vendor’s copy is lower than the price of pretending you have infrastructure you don’t. If your warehouse is already the governed source of truth, the calculus reverses: a second proprietary copy is redundant by construction.
What is the LiveRamp identity graph?
A third-party identity graph: a shared spine of persistent, people-based identifiers used to match and connect records across partners, clouds, and clean rooms. It is optimized for reach, and the trade is dependency — you rent the spine rather than own the substrate. In May 2026, Publicis agreed to acquire LiveRamp for roughly $2.5 billion in cash, expected to close by the end of 2026, which sharpens the neutrality question for anyone deciding whether a shared graph should be a component called for reach or the system of record they depend on.
What is an agentic CDP — is it a fourth architecture?
Not yet. "Agentic CDP" names an overlay on the three architectures compared here, not a fourth procurement alternative: agents become the primary readers of customer data, and an agent needs a governed truth to act on — memory, permissions, and audit live wherever the customer copy lives. That shifts the weights in this comparison rather than adding a column: it strengthens the warehouse-native case for anyone who can operate it, and it raises the packaged exit stakes, because your agents’ accumulated institutional memory joins your segments in the vendor’s copy. The fourth-generation products making this argument are early — much of it is vendor-claimed and architecturally reasoned rather than operationally demonstrated. The full argument is in the agentic CDP essay on this site.
Deciding where the governed copy of your customer should live?
The table narrows it; the constraint decides it. The operating work is mapping your warehouse discipline, identity requirements, and freshness needs to an architecture — and pinning the seams (identity bridge, activation surface, exit terms) before the contract, not after.