TL;DR
The “composable versus packaged CDP” debate is mostly vendor theatre. Composable vendors insist flexibility solves everything. Packaged vendors promise speed and simplicity. Both are right—and both are wrong. The best CDP architecture depends entirely on your technical maturity, implementation urgency, customization needs, engineering capacity, and long-term economics. Ignore the marketing. Architecture should fit your operating model, not a vendor’s sales narrative.
There is a debate running through every MarTech conference, LinkedIn feed, and vendor pitch deck right now. On one side: packaged CDPs are legacy, bloated, and overpriced. On the other: composable architecture is too complex, too expensive to build, and only realistic for companies with a mature data team.
Both sides are wrong. Or more precisely, both sides are right — for the wrong audience.
Why the Composable vs Packaged CDP Debate Gets It Wrong
Because 9 times out of 10, the opinion is presented by the Vendor or its partner.
When a composable CDP vendor tells you that warehouse-native is always faster, cheaper, and more flexible than a packaged CDP, they are describing a world where you already have a data warehouse, a data engineer, a clean event schema, and the runway to absorb an 8–12 week build before a single segment syncs to your email platform.
When a packaged CDP vendor tells you that composable is only for enterprises with massive data teams, they are ignoring the reality that their per-event pricing model will cost you £40,000 a year in billable events generated by anonymous visitors who will never convert.
Neither of these statements is universally true. Both of them are commercially motivated.
CDP Architecture Patterns
From an architecture perspective, CDPs implement three distinct patterns: packaged, composable, and agentic.
| Packaged CDP | Warehouse-Native / Composable CDP | Agentic CDP | |
|---|---|---|---|
| Examples | Segment, mParticle, BlueConic | Hightouch, Census, RudderStack | Emerging — Simon Data, early Salesforce Data Cloud AI features |
| Core premise | All-in-one vendor manages collection, storage, identity, and activation | Your cloud warehouse is the system of record; CDP layer sits on top | AI agents autonomously decide which data to activate, when, and how |
| Who owns the data | Vendor holds it in a managed system | You own it — warehouse is yours | You own the warehouse; agent logic may sit in vendor infrastructure |
| Engineering requirement | Low — UI-driven, connectors pre-built | High — requires dbt, ELT tooling, reverse ETL, ongoing maintenance | Medium to high — model configuration, prompt engineering, guardrails |
As of 2026, the agentic CDP category is too immature for SMBs and high-growth startups to evaluate seriously. Vendor definitions are inconsistent, and the due diligence required — model governance, compliance exposure, data quality prerequisites — is beyond most Series A/B teams. Worth monitoring, not buying. Agentic CDP category is not discussed in this post.
The question is never “which architecture is better.” The question is always “which architecture is better for this company, at this stage, with this team, solving this specific problem.”
Which CDP Is Right for Your Business? It Depends Entirely on Context
Consider two D2C brands, both at Series A, both on Shopify, both running paid social on Meta and TikTok.
- Brand A has 80,000 monthly visitors, a 4% conversion rate, a marketing manager who owns everything, and no data infrastructure beyond Shopify and Klaviyo. Their biggest problem is abandoned cart recovery — they need triggers firing within 20 minutes of a dropout.
- Brand B has 200,000 monthly visitors, a 1.8% conversion rate, a part-time data analyst, and a Snowflake warehouse they set up six months ago for finance reporting. Their biggest problem is LTV modelling — they want to build a propensity model and activate it against their Meta audiences.
Brand A needs a packaged CDP. The real-time activation requirement, the absence of a warehouse, and the non-technical team make composable the wrong call — not because it is inferior, but because the prerequisites are not in place. Brand A would spend more building the foundation than they would save on licensing.
Brand B is a composable candidate. The warehouse exists. The analyst can manage SQL. The primary use case — propensity scoring and batch activation — does not require real-time streaming. And at 200,000 monthly visitors with a low conversion rate, packaged CDP pricing is going to be painful within 18 months.
Same stage. Same model. Completely different answers.
Is a Composable CDP Really Cheaper Than a Packaged CDP?
The composable camp is right that warehouse-native is cheaper at scale. Cloud storage and compute costs in Snowflake or BigQuery are a fraction of per-profile or per-event CDP pricing at high volume. That is not a contested point.
What is contested is whether that cost advantage survives the build.
A composable setup requires engineering investment that a packaged CDP does not. Event collection layer. Schema design. Identity merge logic. Transformation models in dbt. Activation layer via a reverse ETL tool. Each of these components needs to be built, tested, maintained, and extended as your stack evolves. If you have an in-house data engineer, that cost is largely absorbed. If you do not — and most D2C brands at Series A do not — you are looking at agency or contractor costs that can easily run to £20,000–£40,000 for the initial build, plus ongoing retainer for maintenance.
Run that against a packaged CDP at £25,000–£35,000 annually and the three-year economics are closer than either camp will admit. The composable advantage is real. It is not automatic.
How Should You Evaluate a Composable CDP vs a Packaged CDP?
The right way to make this decision is not to read vendor content — including this article. It is to build a capability list specific to your business and evaluate both options against it.
That means working through every layer of your customer data architecture:
- Data Infrastructure — where does your data live today, what is your event volume, and what will it cost you under each pricing model at 2x your current traffic?
- Unification & Modelling — how complex is your customer identity problem? Are customers browsing anonymously across multiple sessions before converting, or do most arrive and buy in a single visit?
- Activation — does your retention strategy depend on triggers firing in minutes, or is batch activation sufficient? This single question eliminates one option for many D2C brands.
- Measurement & Optimisation — does your marketing team need to self-serve on segment creation, or do they have technical support? A team that cannot write SQL cannot operate a composable segmentation layer.
- Governance — how mature are your GDPR processes? Do you need end-to-end data lineage, or is vendor-managed deletion API coverage sufficient for your current compliance obligations?
Work through these layers honestly — based on where your business is today, not where you plan to be — and the answer usually becomes clear. Not because one architecture is better, but because one fits your specific context and the other does not.
Bottom Line
Empirical evidence strongly suggests that most mid-market companies and high-growth startups should default to a packaged CDP approach—but not enterprise suites like Adobe Experience Platform or Salesforce, which can quickly become cost-prohibitive. In this segment, “packaged” should mean lighter-weight, commercially efficient CDPs that prioritise speed and activation over enterprise breadth. Composable architectures only start to make sense once you have the engineering maturity to justify the build cost and ongoing operational overhead. Until then, minimising complexity and capex burn is usually the rational choice.
