Before committing to a composable CDP architecture, data engineers should pressure-test five structural questions that reveal whether the approach fits their organization’s real-world requirements — not just its technical preferences. The composable CDP model offers genuine strengths: data stays in the warehouse you already manage, transformations happen in SQL you already know, and you avoid ceding control to a black-box vendor. These are legitimate engineering values. But the architecture also introduces trade-offs that are easy to underestimate during evaluation and painful to discover in production.
This article walks through five questions designed to surface those trade-offs honestly. None of them have universally right answers. Some organizations will ask these questions and conclude that composable is the correct choice. Others will realize that the operational complexity outweighs the architectural elegance. The goal is to make that decision with full information, not marketing narratives from either side.
1. Where Does PII Actually End Up?
The core promise of a composable CDP is that your data stays in the warehouse. For analytical use cases — segmentation queries, reporting dashboards, ML model training — this is true. Your warehouse remains the single source of truth, and no vendor copies your data into a proprietary store.
But activation changes the picture. When you use reverse ETL to sync audience segments to downstream tools, PII leaves the warehouse on every sync. A customer’s email address, purchase history, and segment membership get copied to your ESP. Their device identifiers and behavioral attributes get pushed to ad platforms. CRM records flow to Salesforce or HubSpot.
Count the systems that hold customer PII after a fully deployed composable stack: the warehouse itself, the reverse ETL tool’s sync cache, each email service provider, each advertising platform, each CRM instance. For a typical mid-market deployment, that is five to eight systems holding some subset of customer PII.
Each system represents a separate Data Processing Agreement. Each requires its own SOC 2 audit review. Each is a distinct breach notification vector under GDPR’s 72-hour reporting requirement. Your CISO and DPO need to evaluate every one of these boundaries, not just the warehouse.
A hybrid CDP with built-in messaging and data activation capabilities keeps PII within one or two system boundaries for most activation use cases. That doesn’t make composable wrong — but it means the “data stays in the warehouse” narrative needs an asterisk for every activation channel you deploy.
The question to ask your team: after full deployment across all activation channels, how many distinct systems will hold customer PII? Is your security team resourced to audit and monitor all of them?
2. Can Your AI Learn from Outcomes in Real Time?
Composable architectures handle batch machine learning well. Training a churn prediction model on warehouse data, scoring customers overnight, and syncing high-risk segments to a retention campaign the next morning — this workflow runs fine on a composable stack. If your AI use cases are purely batch, this section may not apply to you.
But real-time AI use cases expose a structural constraint. Consider the path a closed feedback loop must travel in a composable architecture:
- An AI model queries the warehouse for a customer profile
- The model makes a decision (send offer A vs. offer B)
- Reverse ETL syncs the decision to the ESP (minutes to hours, depending on sync frequency)
- The ESP delivers the message
- The customer acts (opens, clicks, converts — or doesn’t)
- The ESP sends outcome data back to the warehouse (minutes to hours)
- The AI model can now learn from the result
Total loop time: hours to days. For next best action engines or agentic marketing systems that need to read a profile, decide, act, and learn in seconds, this latency is not a configuration problem. It is structural. As long as the decisioning layer and the activation layer are separate systems connected by reverse ETL, the loop cannot close fast enough for real-time learning.
This doesn’t mean composable is broken. It means composable serves a specific set of use cases well and a different set poorly. Be honest about which set your organization is building toward. If your roadmap includes real-time AI decisioning within the next 12 to 18 months, evaluate whether the architecture can get you there — or whether you are building infrastructure that will need to be replaced.
The question to ask your team: what is the minimum acceptable latency for your AI to learn from customer outcomes? Can the composable architecture meet that requirement, or are you planning to solve it later?
3. What Is the Real Total Cost of Ownership?
The entry price of a composable CDP is attractive. Reverse ETL connectors are inexpensive on a per-connection basis. Your warehouse is a sunk cost you’re already paying. The identity resolution layer might be open source or low-cost SaaS. On paper, the bill of materials looks significantly cheaper than a packaged CDP platform.
But the total cost of ownership includes line items that rarely appear in the initial evaluation:
- Warehouse compute: Identity resolution queries and segment materialization are computationally expensive. Organizations routinely report that CDP-related workloads increase their Snowflake or BigQuery bill by two to three times. These queries run frequently, scan large tables, and cannot be easily optimized without degrading match quality.
- Per-row and per-sync pricing: Many reverse ETL tools price on rows synced per month. This scales non-linearly as you add activation channels and increase sync frequency. A sync that costs $500 per month at launch can cost $5,000 per month at scale.
- Engineering headcount: Someone needs to maintain the pipelines, monitor sync health, debug failures, handle schema changes, and manage version upgrades across multiple tools. This is not a set-and-forget deployment. Estimate at least one full-time data engineer for ongoing operations, often more.
- Multi-vendor contract management: Procurement, legal review, and vendor management across four to six tools creates a suite tax that is real even if it doesn’t appear on a cloud bill.
- Security audit costs: SOC 2 review and vendor security assessments cost $15,000 to $30,000 per vendor per year. Multiply by the number of tools in your stack.
G2 reviews of composable CDP tools frequently cite unexpected cost escalation as the top complaint. The three-year TCO — including warehouse compute, per-row pricing at scale, engineering time, and security audits — often exceeds the licensing cost of a packaged platform that includes activation and AI natively.
The question to ask your CFO: model the three-year TCO of the composable stack, including all of the above, and compare it to a customer data platform with built-in activation. Which is actually cheaper?
4. What Happens When a Sync Fails at 2 AM?
A composable stack has four to five distinct failure points in the activation path: the warehouse, the reverse ETL tool, the identity resolution service, the ESP or ad platform, and the orchestration layer. Each is a separate system with its own uptime SLA, its own error handling, and its own support team.
When a campaign fails to send because a segment didn’t sync, the investigation spans multiple systems. Was it a warehouse query timeout? A reverse ETL API rate limit? An ESP authentication token expiration? A schema mismatch between the identity layer and the activation tool? Each possibility requires checking a different vendor’s dashboard and potentially opening a separate support ticket.
Mean time to recovery is structurally higher in multi-vendor architectures because diagnosis requires cross-system correlation that no single vendor’s monitoring covers. You will build custom alerting. You will create runbooks that span four dashboards. You will staff on-call rotations for pipeline operations that, in a single-platform CDP, are the vendor’s responsibility.
This is manageable for organizations with mature data platform teams and existing on-call culture. It is a significant operational burden for teams that adopted composable to avoid the complexity of a monolithic platform and instead inherited a different kind of complexity.
The question to ask your team: who is on-call for the composable stack? Is your data engineering team staffed and willing to own 24/7 pipeline operations for marketing activation?
5. Are You Building a CDP or Building Infrastructure to Avoid Buying One?
This is the honest self-reflection question. It is not a gotcha.
Start listing what a fully deployed composable CDP requires: a warehouse for storage, an ingestion layer for data collection, an identity resolution engine, a segmentation and audience builder, a reverse ETL tool for activation, an orchestration layer for journey logic, and increasingly, an AI layer for decisioning. Add monitoring, alerting, and operational tooling.
That is a customer data platform. You are building a custom CDP from components, not avoiding a CDP. The distinction between “composable CDP” and “CDP built from composable parts” is semantic, not architectural.
There are legitimate reasons to build rather than buy. Your data governance requirements may be unusually strict. Your existing warehouse investment may be too large to duplicate. Your engineering team may have the capacity and the preference to own the full stack. These are valid business reasons.
But many organizations adopt composable architectures because the engineering is technically interesting — SQL-based transforms are elegant, the tool ecosystem is exciting, and “we built it ourselves” carries professional satisfaction. Technical interest is not the same as business justification.
Data engineers’ time has enormous opportunity cost. Every month spent building and maintaining CDP infrastructure is a month not spent on revenue-generating data products, ML models, or customer-facing analytics. If three engineers spend six months replicating what a packaged AI-native CDP delivers out of the box, the opportunity cost alone may exceed the platform’s licensing fee.
The question to ask your leadership: given the total effort required, is building composable CDP infrastructure the highest-value use of your data engineering team’s time? What would they build instead?
Making the Decision
These five questions do not have predetermined answers. An organization with purely batch use cases, a strong data platform team, a modest activation footprint, and strict data residency requirements may answer every question and correctly conclude that composable is the right architecture.
But an organization planning real-time AI use cases, activating across many channels, operating with a lean data team, or subject to rigorous security audits may find that the composable model introduces more complexity than it eliminates. In that case, a hybrid CDP that combines warehouse connectivity with built-in activation and AI deserves serious evaluation — not because composable is wrong, but because the trade-offs don’t favor it for that specific context.
The worst outcome is choosing an architecture based on narrative rather than requirements. Ask the questions. Do the math. Let the answers guide the decision.
For a broader evaluation framework covering both composable and hybrid architectures, see How to Evaluate a CDP in the AI Era.
FAQ
Is a composable CDP cheaper than a packaged CDP?
At entry scale, composable stacks often cost less in direct licensing fees. However, three-year total cost of ownership — including warehouse compute increases of two to three times for identity resolution and segmentation queries, per-row reverse ETL pricing at scale, engineering headcount for pipeline maintenance, and SOC 2 audit costs per vendor — frequently exceeds packaged CDP licensing. Organizations should model full TCO across all cost categories before comparing sticker prices.
Can a composable CDP support real-time AI use cases?
Composable architectures handle batch AI well, including churn prediction, lifetime value scoring, and overnight segment generation. Real-time AI use cases — such as next best action engines and agentic marketing systems — require closed feedback loops that complete in seconds. The structural separation between the decisioning layer in the warehouse and the activation layer in external tools, connected by reverse ETL with minutes-to-hours latency, prevents these loops from closing fast enough for real-time learning.
How many engineers does a composable CDP require to maintain?
A production composable CDP deployment typically requires at least one full-time data engineer for ongoing operations: pipeline monitoring, sync debugging, schema management, tool upgrades, and on-call coverage. Organizations with complex activation requirements or high reliability expectations often dedicate two to three engineers. This is in addition to the initial build effort, which commonly spans three to six months with two or more engineers. The suite tax of managing multiple vendor relationships adds further overhead beyond direct engineering time.
Related Terms
- Composable CDP — The architecture this article evaluates, built from modular best-of-breed tools
- Hybrid CDP — The alternative architecture combining warehouse connectivity with built-in activation
- Closed Feedback Loop — The real-time learning cycle that composable architectures struggle to close
- Reverse ETL — The sync mechanism that moves data from warehouse to activation tools
- AI-Native CDP — CDP architecture with AI built into the platform rather than bolted on