Composable CDP vs. Packaged CDP: The Bitter Truth for Mid-Market
Composable CDP sounds like progress in 2026, but in mid-market it often fails on hidden engineering costs. When packaged wins, when composable wins, honestly decided.
By Juri Saloid 4 min read The hype and the reality
On LinkedIn the matter is settled in 2026. Every other post declares the packaged CDP dead and celebrates composable as the only grown-up architecture. Full data ownership, no vendor lock-in, everything in your own warehouse. Sounds compelling.
In practice it looks different.
We regularly take over setups where a mid-market company followed the hype, started a composable architecture and got stuck after six months. Not because the idea was wrong. Because nobody finished the maths. A composable CDP is not a product you buy. It is a system you build, run and maintain, permanently.
This is exactly where mid-market parts ways with enterprise. A corporation has the data team to carry such a system. The typical mid-market company has a marketing lead, half an analytics role, and not a single data engineer.
What is what?
- Packaged CDP
A ready-made SaaS platform (Segment, Tealium) that bundles data collection, identity resolution and activation into one product. You buy speed and give up control and data ownership in return.
- Composable CDP
A stack assembled from building blocks on your own warehouse (BigQuery + dbt + Hightouch or Census). You keep full control and carry the full complexity and operational load in return.
Black box: simple, but inflexible. You see only what the platform allows.
The illusion of cost
The strongest sales pitch for composable is price. A packaged CDP quickly costs five figures a month, the licence scales ruthlessly with tracked users. Composable runs on BigQuery, which costs a fraction with a clean setup. On paper a clear win.
On paper.
What the maths leaves out: composable replaces a licence with work. Someone has to build the pipelines, write the dbt models, solve identity resolution, maintain the Hightouch syncs and keep it all running when a sync breaks at 11pm. That someone is a data engineer, and data engineers are expensive and scarce in 2026.
Do the honest maths: a composable architecture with no in-house engineer quickly lands at €9,000 a month for external help and recruiting alone. The saved licence is more than eaten up. With two engineers who carry the system anyway, the maths tips clearly in favour of composable.
The licence is visible. The engineering cost is not. That is exactly why composable gets systematically underestimated in mid-market.
TCO reality check
The licence is only half the bill. Drag data volume and team size, the real cost comparison updates live.
External consultants & recruiting eat the ROI.
Model estimate, not binding list prices. Packaged scales with MTUs, composable with infrastructure plus what engineering actually costs.
Real-time vs. batch
The second blind spot is latency. Marketing wants to reach the cart abandoner in the moment they abandon, not two hours later. Sub-second triggers are the use case where the architectures part.
Packaged CDPs are built for it. Streaming ingestion, near-real-time event triggers, configured and ready. A composable CDP on BigQuery, by contrast, mostly works in batch or micro-batch in 2026. Reverse-ETL tools like Hightouch sync in intervals, not in milliseconds.
This is solvable, but not for free. True real-time in the composable stack means an extra streaming layer (say Pub/Sub plus a streaming engine), and that is more engineering for someone to build and run. For most mid-market use cases micro-batch is plenty. But if you genuinely need sub-second triggers, packaged gives them to you faster and cheaper.
A decision matrix for mid-market
Forget the LinkedIn consensus. The choice hangs on your team and your foundation, not on fashion.
Packaged CDP wins when:
- you need sub-second triggers and have no warehouse foundation yet.
- there is no data engineer on the team, and none is coming.
- time-to-value counts in weeks, not quarters.
Composable CDP wins when:
- BigQuery is already your single source of truth.
- at least two data engineers carry the system long-term.
- data ownership, EU region and arbitrary modelling are hard requirements.
The most honest answer is often a hybrid: composable as the backbone for analysis and modelling, a lean packaged or streaming layer only where genuine real-time is needed. Not every architecture has to be a religion.
Decision engine: packaged or composable?
Two questions settle most cases. Answer them honestly.
Do you need real-time triggers under 1 second (e.g. ad-hoc cart abandonment)?
Is BigQuery already your single source of truth?
Answer both questions and the recommendation appears.
Unsure which architecture fits your team? An Audit Sprint reviews your data, team and use cases, and delivers a reasoned recommendation within two weeks: packaged, composable or hybrid.
Need help with your setup?
Audit Sprint in two weeks, prioritised report, concrete action steps.
Request an audit →-
Is composable CDP always the more modern choice?
More modern as an architecture, yes. But more modern doesn't mean better for everyone. Without an in-house data-engineering team, a packaged CDP is often the more sensible and cheaper decision. The best architecture is the one your team can carry.
-
What does a composable CDP really cost?
The infrastructure (BigQuery, dbt, reverse ETL) is cheap, often under €1,000 a month. The real cost block is engineering. Without in-house data engineers, several thousand euros a month for external help and recruiting are added quickly, and that is exactly what most comparisons miss.
-
Can I run real-time campaigns with a composable CDP?
Only to a degree. Reverse ETL mostly runs in batch or micro-batch in 2026, not in real time. For sub-second triggers you need an extra streaming layer. Packaged CDPs deliver this with no extra effort.
-
Do I strictly need BigQuery for composable?
Not strictly, but it is the pragmatic standard for DACH setups on GA4. A warehouse as the single source of truth is the precondition. Snowflake works just as well, BigQuery is usually closer to the existing Google data.
-
What do you recommend the typical mid-market company?
Honestly: if the warehouse isn't in place and the engineering team is missing, you move faster and safer with packaged. Composable pays off once BigQuery is in place and two engineers carry the system. Until then, building the infrastructure is the real first step, not the CDP.
About the author