How should enterprises compare self-hosted and managed CDC?
A self-hosted CDC platform gives the customer more control but also more runtime responsibility. Managed CDC transfers selected infrastructure and lifecycle work to a provider, while the customer still owns source configuration, access, data governance, and other shared responsibilities. Hybrid models split the control and data planes, so location, data boundary, and operational ownership must be evaluated separately for each component and workload.
Executive framing: define the operating model before comparing products
Self-hosted and managed CDC are not binary opposites. A useful decision begins with three independent questions: where each component runs, what data crosses each boundary, and who operates each component through failure and change.
In procurement language, a self hosted change data capture platform may also be described as customer managed CDC or an on premises CDC platform. Those search terms express intent, not a complete architecture.
For this guide, self-hosted means the software runs in infrastructure selected and provisioned by the customer; it does not automatically mean a physical data center. On premises refers to infrastructure inside a customer-operated facility or private environment. Customer managed means the customer performs most runtime and lifecycle work, regardless of location. Managed means a provider assumes specified operating duties. Hybrid means planes or responsibilities are split. Customer-controlled means the customer controls a defined environment or access boundary, but the term says nothing by itself about patching, telemetry, support access, or service ownership.
Vendor labels vary. Request component and network diagrams for the exact offer, region, connector, and version under evaluation. The diagrams should show sources, capture workers, brokers or buffers, control services, state stores, destinations, observability paths, backups, and human access. Without that evidence, a deployment label is only shorthand.
What are the four actual CDC deployment models?
Most buying choices map to four models, but one vendor may offer several and one workload may combine them. Treat the table as a taxonomy, not a product ranking.
| Model | Typical component location | Primary operator | Buyer advantage | Question that prevents surprises |
|---|---|---|---|---|
| 1. Self-hosted, self-managed | Data and control components run in a customer data center, private cloud, or customer cloud account. | Customer platform, database, security, and on-call teams. | Potentially greater topology and change-window control, subject to the product and operating model. | Do we have durable ownership for dependencies, upgrades, state, recovery, and specialist coverage? |
| 2. Managed SaaS | Provider environment hosts most service components; connectivity reaches customer sources and destinations. | Provider operates the service; customer retains workload and shared-security duties. | Less infrastructure and service-lifecycle work. | Which payload, metadata, credentials, logs, state, and support artifacts cross the provider boundary? |
| 3. Hybrid control plane and data plane | Processing runs in the customer environment while management services run with the provider. | Split by component and deployment contract. | Local processing with centralized service management. | What travels outbound, and who upgrades, monitors, and recovers the local runtime? |
| 4. Vendor-managed in a customer-controlled environment | Service components run in a customer-controlled account or facility; provider access may be direct, mediated, or absent. | Provider and customer divide operations under an explicit access model. | Customer environment control with selected vendor operations. | How do access, patching, backup, incident command, and disconnected operation work in practice? |
Examples across the market show why the spectrum matters. Some hybrid services pair customer-run processing or data planes with a vendor-managed control plane. Self-managed CDC frameworks place workers, configuration, offsets, status storage, security, scaling, and recovery in the customer-operated system. Serverless managed services may automate provisioning, scaling, high availability, engine versions, and patching while customers still configure endpoints, replication behavior, and lifecycle actions. These are operating patterns, not a universal ranking.
Which boundaries belong on the architecture map?
The boundary review must cover more than replicated rows. Metadata, checkpoints, credentials, logs, temporary storage, support bundles, and administrator access can carry operational or sensitive context.
| Boundary area | Map explicitly | Decision evidence |
|---|---|---|
| Data plane | Capture, snapshot, transform, buffer, transport, destination apply, and dead-letter paths. | Component locations, ports, encryption, keys, payload classes, temporary copies, and cross-region movement. |
| Control plane | Pipeline creation, scheduling, orchestration, policy, identity, and administrative APIs. | Hosting account, operators, authentication, outbound requirements, and failure behavior when disconnected. |
| Metadata | Schema, table names, configuration, job status, usage, schedules, and asset identifiers. | Fields exported, retention, region, subprocessors, deletion, and masking options. |
| Observability and support | Metrics, traces, logs, alerts, diagnostics, and support bundles. | Content filters, retention, recipient, redaction, export controls, and escalation workflow. |
| Checkpoint and state | Offsets, log positions, transaction state, connector configuration, and replay markers. | System of record, durability, access, portability, restore procedure, and corruption handling. |
| Backup and disaster recovery | Configuration, state, buffers, keys, and replicated data copies. | Region, ownership, frequency, restore test, recovery objective, and failover authority. |
| Remote access | Vendor support, customer administrators, automation identities, break-glass access, and update channels. | Approval path, audit trail, session controls, privilege scope, expiry, and offline alternative. |
Security and compliance responsibility does not disappear in any model; where a provider participates, responsibilities remain shared and service-specific. Major cloud-provider responsibility models continue to assign customers duties for areas such as data, identity, access, configuration, and workload-specific controls. An attestation can support the review, but it does not replace a pipeline-specific threat model or evidence for the deployed topology.
Who owns the CDC lifecycle?
Ownership must be assigned task by task. The matrix below is a negotiation worksheet, not a universal RACI: “customer,” “provider,” “shared,” and “verify” indicate the expected discussion, while formal Responsible, Accountable, Consulted, and Informed assignments remain workload-specific.
| Lifecycle task | Self-managed | Managed SaaS | Hybrid split-plane | Vendor-managed in customer environment |
|---|---|---|---|---|
| Source preparation and log retention | Customer | Customer | Customer | Customer or shared |
| Install or provision runtime | Customer | Provider | Shared | Shared; verify access |
| Connector and mapping configuration | Customer | Customer or shared | Customer or shared | Shared |
| Patch and upgrade | Customer | Provider; customer validates | Shared; verify local agent | Shared; verify change window |
| Capacity and scaling | Customer | Provider or shared | Shared | Shared |
| Monitoring and alert response | Customer | Shared | Shared | Shared |
| Backup and restore | Customer | Provider or shared; verify scope | Shared; verify state boundary | Shared; verify authority |
| Incident response | Customer | Shared | Shared | Shared |
| Connector compatibility and schema change | Customer | Shared | Shared | Shared |
| Security and compliance evidence | Customer | Shared | Shared | Shared |
| Exit, state export, and migration | Customer | Shared; verify portability | Shared; verify portability | Shared; verify access removal |
Managed operation removes selected infrastructure work, not all customer responsibility. Source-side CDC still depends on engine-specific transaction logs, privileges, settings, retention, and available capacity. Managed connectors can also have version compatibility rules, cloud or region limits, network constraints, payload limits, schema or DDL behavior, start-point restrictions, deprecation events, and recovery controls. Confirm the exact connector rather than assuming platform-wide behavior.
Hosting also does not determine correctness. Some self-managed connectors document possible duplicates in crash and network-recovery paths. Some managed services use at-least-once delivery, do not guarantee ordering, or can produce duplicates during regional recovery. Continuous capture may be described as near-real-time rather than carrying a universal real-time latency guarantee. End-to-end latency and delivery depend on source workload, network, capacity, connector configuration, checkpointing, transport, target apply behavior, and the tested failure boundary.
How should buyers calculate CDC total cost of ownership?
Compare like-for-like operating scope over the same horizon. A practical worksheet is: 3-year TCO = platform + infrastructure + people + change + incident risk + exit cost.
| Worksheet line | Inputs to declare | Often missed |
|---|---|---|
| Platform | License, support, base plan, connector entitlement, capacity, task, or volume meters. | Premium connectors, environments, support tier, minimum commitments, and price changes. |
| Infrastructure | Compute, brokers, storage, retained logs, private connectivity, public IP, and network transfer. | Headroom, cross-zone or cross-region traffic, downstream processing, test, and DR environments. |
| People | Platform engineering, DBA, SRE, security, FinOps, procurement, training, and on-call coverage. | Loaded labor rate, specialist scarcity, incident coordination, and vendor management. |
| Change | Upgrades, schema changes, connector migrations, security reviews, and capacity growth. | Deprecation or end-of-life events, regression testing, custom code, and change windows. |
| Incident risk | For each scenario, estimated annual frequency or probability × monetized impact, including recovery labor and business exposure. | Expired source logs, replay, deduplication, reconciliation, audit work, and opportunity cost. |
| Exit cost | Contract transition, data and state export, replacement build, parallel run, and skills transfer. | Checkpoint portability, retained history, egress, access removal, and final reconciliation. |
Use the same source and target versions, change volume, pipeline count, environments, regions, retention, recovery targets, security boundary, growth curve, staffing model, and incident assumptions. Run sensitivity ranges rather than one precise forecast. Managed services may meter capacity, tasks, CDC volume, backfill, storage, networking, or downstream processing in different combinations. Those invoice lines are not comparable without workload assumptions. There is no universal cost winner.
Which model fits regulated, air-gapped, or multi-region workloads?
The right model follows the verified boundary and recovery design, not the label. Regulation does not automatically require self-hosting, and customer location does not automatically establish isolation, operability, or compliance.
| Workload context | Potentially suitable models | Required validation | Warning |
|---|---|---|---|
| Regulated or residency-constrained | Any model whose full data, metadata, identity, support, backup, and subprocessor boundaries satisfy policy. | Data classification, region, keys, IAM, audit evidence, retention, support access, and deletion. | “Runs in your VPC” does not define every outbound flow or responsibility. |
| Air-gapped or disconnected | Usually customer-environment models designed for verified offline operation. | Licensing, telemetry, updates, time, certificates, artifact delivery, support, and vulnerability response without outbound access. | A deployment label alone does not prove disconnected operation. |
| Multi-region continuity | Any model with tested state, source-log, destination, and operator recovery across the required regions. | RPO and RTO boundaries, checkpoint replication, failover authority, duplicate handling, reconciliation, capacity, and drills. | Infrastructure presence in two regions does not establish end-to-end recovery. |
What five steps produce a defensible CDC selection?
A disciplined selection moves from workload facts to contractual ownership. It avoids choosing a label first and discovering the operating model later.
- Define the production workload. Record exact source and target versions, transaction patterns, change volume, sensitive data, schema frequency, acceptable source impact, latency objective, RPO, RTO, retention, and growth.
- Draw the planes and flows. Place every data, control, metadata, state, observability, backup, update, and support component. Mark regions, accounts, trust zones, network direction, credentials, and operators.
- Assign lifecycle ownership. Convert the responsibility matrix into deployment-specific RACI entries. Name the accountable team, provider obligation, escalation point, evidence, change window, and fallback for each task.
- Model three-year cost and risk. Apply the formula above with common assumptions and sensitivity ranges. Keep provider invoices, customer infrastructure, labor, incident exposure, and migration visible.
- Prove and contract the result. Run a production-shaped PoC, retain evidence, resolve exceptions, and align architecture diagrams, security exhibits, service descriptions, support terms, and exit provisions.
What belongs in a production-shaped PoC?
The PoC should test the failure modes and operating handoffs that determine production risk. A happy-path snapshot proves connectivity, not lifecycle fitness.
| Test | Failure or change to introduce | Evidence to retain |
|---|---|---|
| Initial load plus writes | Snapshot representative large tables during realistic transactions. | Source CPU and I/O, log growth, consistency boundary, duration, and reconciliation. |
| Steady-state load | Use realistic bursts, large transactions, deletes, data types, and target constraints. | Lag distribution, throughput, resource use, target correctness, and cost-meter output. |
| Network and component loss | Interrupt source, control plane, worker, broker, destination, and regional paths separately. | Checkpoint behavior, backlog, alerts, duplicates, ordering, operator actions, and recovery time. |
| Log retention pressure | Hold the pipeline beyond a planned outage and approach source-log expiry. | Warning lead time, restart or resnapshot path, capacity impact, and runbook accuracy. |
| Schema and connector change | Exercise additive and breaking DDL, connector upgrade, and a lifecycle migration. | Compatibility decision, blocked or propagated changes, rollback, and ownership handoff. |
| Security and support | Rotate secrets, revoke access, export diagnostics, and invoke support under controlled conditions. | Least privilege, audit trail, redaction, approval, response boundary, and residual access. |
| Backup, restore, and exit | Restore state to a clean environment, export configuration, and rehearse provider removal. | Portable artifacts, dependencies, elapsed time, reconciliation, and documented gaps. |
How can teams evaluate Deltaplex for this operating model?
Teams evaluating Deltaplex can begin with the same four questions used throughout this guide: where components run, what crosses each boundary, who operates each lifecycle task, and how recovery works under failure. The appropriate design depends on the customer’s topology, security policies, source and destination systems, and preferred division of responsibility.
Map capture, processing, state, observability, backup, and support paths before selecting a deployment pattern. Then use a production-shaped proof of concept to confirm connector fit, source impact, recovery behavior, schema handling, operational visibility, and the support workflow for the selected topology.
This workload-first approach keeps the decision practical without assuming that one deployment label fits every environment.
Conclusion: choose the operating boundary that fits the workload
Neither self-hosted nor managed CDC wins universally. Choose the model whose verified boundaries, connector behavior, operating responsibilities, recovery design, and cost profile fit the specific workload and organization.
A mature platform team may prefer self-managed control for strategic pipelines. A standardized cloud path may favor managed SaaS. A hybrid control plane can suit buyers that want customer-local processing with provider-operated coordination. Vendor management inside a customer-controlled environment can fit another set of access and ownership requirements. The decisive evidence is the topology, responsibility matrix, failure test, and three-year model—not the category name.
Review your CDC operating model
Bring your topology, boundaries, recovery objectives, and ownership assumptions to an architecture review.
Frequently asked questions
These answers resolve the most common category and procurement questions, while keeping the final decision workload-specific.
Is a self-hosted CDC platform always deployed on premises?
No. Self-hosted describes who deploys and operates the software, not a physical location. It can run in a data center, private cloud, or customer cloud account. Confirm every component and network path.
Does managed CDC remove the customer's operational responsibility?
No. A provider may operate infrastructure, scaling, patching, or availability controls, while the customer still owns source preparation, access, configuration, governance, validation, and workload decisions.
Can a hybrid CDC service keep row data in the customer environment?
It can, depending on the architecture. However, configuration, status, schedules, metrics, logs, or usage metadata may cross to a provider control plane. Verify each data class and exception.
Which CDC model has the lowest total cost of ownership?
There is no universal winner. Compare the same workload, regions, recovery objectives, retention, security boundary, staffing model, growth, incident frequency, and exit assumptions over three years.
Is managed CDC automatically suitable for regulated or air-gapped workloads?
No. Labels alone prove nothing about residency or isolation. Review outbound licensing, telemetry, updates, support access, identity, certificates, artifact delivery, backups, and disaster-recovery paths.
Does hosting choice determine CDC delivery or ordering guarantees?
No. Delivery and order depend on the source connector, checkpoints, transport, destination apply behavior, configuration, and failure boundary. Test retries, recovery, duplicates, and reconciliation end to end.