A pattern keeps showing up in data team conversations: companies letting their Segment or mParticle contracts lapse, then rebuilding activation on top of Snowflake, dbt, and a Reverse ETL tool like Hightouch or Census.
This isn’t a startup cost-cutting move. Notion, Retool, and GitLab have all gone down this path. According to Integrate.io’s early 2026 numbers, the CDP market sits somewhere between $3.71B and $7.51B (the gap comes from whether you count “composable CDPs” in the total), while Reverse ETL tools keep gaining ground. Hightouch now supports 250+ destination integrations. Census closed a $60M Series C led by Tiger Global.
But here’s the part that doesn’t get enough airtime: the composable data stack is not a silver bullet, and its real cost is consistently underestimated.
What Broke With Traditional CDPs
Traditional CDPs were built on a simple premise: every company needs a single centralized platform where all customer data flows in, gets unified, and gets pushed out to activation tools.
Before 2020, this made sense. Most companies had weak data infrastructure, no proper warehouse, and nothing like dbt for transformation. CDPs offered a packaged solution: plug in your sources, run identity resolution, build profiles, sync to marketing tools.
The infrastructure environment shifted underneath them.
Snowflake, BigQuery, and Databricks became the de facto “source of truth” for most mid-market and enterprise teams. dbt made transformations standardized and version-controlled. Against this backdrop, the traditional CDP started looking redundant: it asks you to copy your data into yet another platform, re-model it under its schema, and run identity resolution by its rules.
Three pain points emerged:
Data latency. Every hop between systems adds delay. Many traditional CDPs sync on hourly or daily cadences. For a B2B SaaS company running product-led growth motions, that lag kills the feedback loop between product behavior and marketing action.
Data consistency. When your warehouse has one version of a user profile and your CDP has another (and they will diverge), which one do your teams trust? This becomes a governance nightmare.
Cost escalation. Traditional CDPs charge by MTU (monthly tracked users). Segment’s enterprise tier runs $100K+/year easily. What you’re paying for, at its core, is data transportation: moving data you already own into someone else’s system.
How the Composable Architecture Works
The composable data stack starts from a straightforward principle: if the data already lives in your warehouse, activate it directly from there.
The architecture looks like this:
Sources → ETL (Fivetran/Airbyte) → Warehouse (Snowflake/BigQuery) → dbt transformation → Reverse ETL (Hightouch/Census) → Downstream tools (Salesforce, HubSpot, ad platforms)
Each layer is independent and swappable. Fivetran pricing doesn’t work for you? Swap in Airbyte. Your dbt models need refactoring? Change them without touching other layers. Hightouch raises prices? Census plugs into the same warehouse.
The advantages are concrete:
Single source of truth. Every downstream tool reads from the same data. Consistency problems disappear because there’s only one canonical dataset.
SQL-level flexibility. You can define any audience segment you want, unconstrained by a CDP’s pre-built models. “Users who viewed the pricing page 3+ times in the last 7 days but haven’t started a trial” is one SQL query away.
Lower tool costs. Reverse ETL pricing runs roughly an order of magnitude below traditional CDPs. Hightouch starts at $350/month. Census is in the same range. Compare that to Segment’s six-figure annual contracts.
The Hidden Costs Nobody Wants to Talk About
This is where most composable-stack advocacy falls apart, because it stops at tool pricing and ignores people costs.
CDP.com published an analysis in May 2026 with a sobering number: composable data stacks typically require 3 to 5 dedicated data engineers (at $150K-$200K/year each) handling warehouse modeling, identity resolution pipelines, connector maintenance, and on-call rotations.
Run the math: 3 data engineers × $175K/year = $525K/year in salary alone. Add Snowflake compute costs, dbt Cloud licensing, and Reverse ETL subscriptions, and total cost of ownership (TCO) can exceed what a traditional CDP would have cost.
| Cost Component | Traditional CDP | Composable Stack |
|---|---|---|
| Platform/tool spend | $100K-$300K/year | $30K-$80K/year (Reverse ETL + warehouse compute + dbt Cloud) |
| Engineering headcount | 0-1 dedicated engineers | 3-5 dedicated engineers |
| People cost (loaded) | $0-$175K/year | $525K-$875K/year |
| Identity resolution | Included | Build and maintain in-house |
| Connector maintenance | Vendor-managed | Team-managed (schema changes, API updates) |
| Estimated total TCO | $100K-$475K/year | $555K-$955K/year |
The traditional CDP is expensive, but it encapsulates complexity. You don’t build identity resolution yourself (one of the hardest problems in data engineering). You don’t maintain hundreds of connectors. You don’t handle schema drift and data quality issues.
The composable stack hands all that complexity back to your team. If your team can absorb it, you gain flexibility and control. If they can’t, you end up with a more expensive and more fragile system than what you replaced.
Real-Time: The Structural Weakness
There’s a second problem that rarely surfaces in composable-stack marketing: the architecture is fundamentally batch-oriented.
When an AI agent needs to personalize a user’s experience in real time while they’re browsing your app, it needs sub-second profile lookups and instant activation. But the composable data flow looks like this:
Event occurs → ETL syncs to warehouse (minutes) → dbt model rebuilds (minutes to hours) → Reverse ETL syncs downstream (minutes)
End-to-end latency lands in the minutes-to-hours range. For scenarios like “this user just added an item to their cart, send a discount within 30 seconds,” the composable architecture cannot deliver.
Traditional CDPs have a structural advantage here: data stays within their platform, enabling second-level or even millisecond-level response times.
With AI agents increasingly participating in real-time decisioning throughout 2026, this gap matters more than it did two years ago. If your business depends heavily on real-time personalization, a pure composable setup will leave you short.
Decision Framework: Which Architecture Fits Your Team
Based on patterns across dozens of B2B SaaS companies, composable stacks work well when these conditions are met:
You already have a mature warehouse and dbt practice. If your warehouse contains clean, well-modeled user tables, the composable approach just adds an activation layer on top. Marginal cost stays low.
You have 2+ data engineers on staff. Identity resolution, data quality monitoring, and pipeline maintenance need dedicated ownership. Without that headcount, don’t attempt composable.
Your primary use cases are batch activation. Email campaigns, ad audience syncs, CRM enrichment: these tolerate minutes or hours of latency. Composable handles them well.
You have strong data governance requirements. Financial services and healthcare companies that cannot send customer data through third-party platforms benefit from keeping everything in their own warehouse.
Conversely, stay with a traditional CDP if:
You lack a data engineering function. If your “data team” is a single analyst who writes SQL, you need the out-of-the-box capabilities a packaged CDP provides.
Real-time personalization drives revenue. In-app triggers, real-time recommendations, and session-based routing still work better inside a traditional CDP’s event-streaming architecture.
Cross-device identity resolution is critical. Merging user identities across devices and channels is an extraordinarily complex engineering problem. Traditional CDPs have spent a decade refining this capability. Building it from scratch carries high cost and high risk.
The 2026 Compromise: Hybrid Architecture
In practice, more companies are landing on a middle path: use the warehouse for batch analytics and activation, layer in a lightweight CDP or event stream for real-time scenarios.
A common setup: Snowflake + dbt + Hightouch handles daily marketing automation and audience syncing, while a lightweight event pipeline (RudderStack’s real-time stream, for example) covers in-session triggers.
Hightouch itself is moving in this direction. Its “AI Decisioning Platform” attempts to bolt real-time decision capabilities onto a warehouse-native architecture. It’s not as mature as a traditional CDP’s real-time layer yet, but the trajectory is clear.
This hybrid approach typically reduces TCO by 30-50% compared to a pure traditional CDP while covering most real-time use cases. The tradeoff is higher architectural complexity and a team that understands where one system ends and the other begins.
Migration Realities
Timeline. Typical CDP-to-composable migrations run 3 to 6 months. The bottleneck isn’t technical implementation; it’s rebuilding user models and identity resolution logic inside the warehouse. Phase it: start with batch use cases (ad audiences, email lists), tackle real-time scenarios last.
Hightouch vs. Census. Hightouch has more destination integrations (250+ vs. Census at 150+), making it better for teams with many downstream tools. Census offers tighter dbt-native integration, appealing to heavy dbt users. Pricing is similar. Functional overlap is high. The choice rarely makes or breaks the architecture.
Minimum warehouse requirements. At minimum: a cloud warehouse (Snowflake, BigQuery, Databricks, or Redshift) with clean user tables. Ideally: a dbt project managing transformation logic, data quality tests (dbt tests or Great Expectations), and a documented data dictionary.
Small teams (5-10 people). If you have 1-2 people comfortable with dbt and SQL, and your use cases are primarily batch activation, Hightouch or Census at entry-tier pricing (~$350/month) can support a lightweight composable setup. But if you haven’t built a warehouse yet, do that first.
Where This Is Heading
The composable data stack is not “a better CDP.” It represents a different philosophy about where data modeling and activation logic should live.
For teams with the engineering depth to own that complexity, composable delivers greater flexibility, lower long-term tool costs, and stronger data governance. For teams that just need marketing to self-serve audience segments and trigger campaigns, a packaged CDP remains the more pragmatic choice.
The 2026 reality for most growth-stage B2B SaaS companies (Series B through D): the migration toward composable is happening, but moving slower than vendors predicted. Identity resolution and real-time activation remain harder to replicate than anyone expected.
The pragmatic path for most teams: cover 80% of use cases with composable batch activation, fill the remaining 20% with a lightweight real-time solution. Avoid the temptation to migrate everything at once. That road is lined with stalled projects and blown timelines.
Stay updated with our latest AI insights
