“Zero-ETL” has become one of the most overloaded phrases in data engineering. Cloud providers use it for native replication between their own services, ingestion vendors use it for fully managed connectors, and engineers use it, sometimes sarcastically, for anything that hides the pipeline from view. Meanwhile, open source change data capture (CDC) with Debezium or Flink CDC remains the workhorse behind many real-time platforms. Choosing among these options is now one of the most consequential integration decisions a data team makes, because it determines cost, lock-in, operational load and how far your data can travel beyond a single platform.
This guide defines the three options precisely, compares them on the criteria that matter in practice, and offers a scoring model you can apply flow by flow rather than making one platform-wide bet.
Defining the Three Options
Zero-ETL integrations
Zero-ETL refers to replication built into a data platform, configured with a few clicks, that continuously copies data from a source into an analytics target without a separately managed pipeline. AWS has pushed the idea furthest. Its zero-ETL integrations replicate from Aurora, RDS and DynamoDB into Redshift and Amazon SageMaker’s lakehouse; in July 2025 AWS Glue added zero-ETL from DynamoDB and eight applications, including Salesforce, SAP, ServiceNow and Zendesk, into Amazon S3 Tables with built-in Apache Iceberg support; and in November 2025 it extended zero-ETL to self-managed Oracle, SQL Server, MySQL and PostgreSQL databases replicating into Redshift. The defining traits are minimal configuration, no infrastructure for you to run, and tight coupling to a specific source and target pairing.
Managed ingestion connectors
Managed connectors are hosted services, offered either by your data platform or by an independent integration vendor, that pull from many sources and load into one or more targets. Databricks Lakeflow Connect (with a generally available SQL Server connector using CDC and Change Tracking since September 2025), Snowflake Openflow (curated Apache NiFi flows with database CDC and SaaS connectors, deployable in your own cloud or in Snowflake), and independent vendors such as Fivetran fall into this group. You configure rather than code, but you typically get more control than zero-ETL: schedules, column selection, history modes, and deployment through Terraform or CI/CD bundles.
Self-managed CDC
Self-managed CDC means running open source capture yourself, most commonly Debezium on Kafka Connect, Debezium Server (which can send changes to Kinesis, Pub/Sub or HTTP without Kafka), or Flink CDC. You own the infrastructure, the event formats and the operations. In exchange you get portability across clouds and targets, the ability to fan out the same change stream to many consumers, and control over every configuration knob.
The trade-off is real operational responsibility. Someone has to size and upgrade the Connect cluster, watch replication slot lag on PostgreSQL sources, manage schema registry compatibility rules, rehearse replays from stored offsets, and respond at 3 a.m. when a long-running transaction stalls the stream. Organizations that already run Kafka for application messaging absorb this easily; organizations without a platform team often discover that the license savings were paid for in engineering hours.
The Comparison That Matters
Vendor comparisons tend to focus on connector counts. In our experience, the decision turns on seven criteria.
- Source and target coverage. Zero-ETL covers specific pairs. Managed connectors cover broad source catalogs but usually one target platform (or one vendor’s list of destinations). Self-managed CDC covers any source with a connector and any target you can write to.
- Fan-out. If the same changes must reach a lakehouse, a search index, a cache and a microservice, a replayable event log beats point-to-point replication. Zero-ETL and most managed connectors are designed for one destination per integration.
- Latency. All three can deliver near-real-time data, but managed connectors often run on schedules, and zero-ETL latency is governed by the provider. Self-managed streaming gives you the most control, at the cost of tuning.
- Transformation and filtering. Zero-ETL generally replicates as-is and leaves transformation to the target. Managed connectors offer column selection and history modes. Self-managed pipelines can filter, mask and enrich in flight.
- Operational burden. Zero-ETL is lowest, managed connectors are low, and self-managed CDC is highest: upgrades, scaling, offset management, replication slot monitoring and on-call.
- Cost model. Zero-ETL is often priced through compute and storage on the target. Managed connectors frequently charge by rows or volume moved, which can surprise teams with high-churn tables. Self-managed CDC costs infrastructure plus engineering time, which is easy to underestimate.
- Lock-in and portability. Zero-ETL ties you to a platform pairing. Managed connectors tie you to a vendor’s configuration model. Self-managed CDC is the most portable, especially when sinks write to open table formats such as Iceberg or Delta.
Total cost of ownership, not list price
Cost comparisons go wrong when they compare a connector invoice against the cloud bill for a few Kafka brokers. A fair comparison over three years includes five components: the platform or vendor charges for moving data; target compute spent on merges and history tables; infrastructure for any self-managed transport and processing; engineering time to build, upgrade and troubleshoot; and the cost of incidents, measured as hours of stale or wrong data multiplied by what that staleness costs the business. Self-managed CDC typically looks cheapest on infrastructure and most expensive on people. Volume-priced managed connectors look cheap for slowly changing SaaS objects and expensive for high-churn transactional tables. Zero-ETL often shifts cost onto the target, where continuous merges consume compute that someone has to budget for.
A useful habit is to run a two-week proof of value on your highest-volume table with the candidate options side by side, measuring rows moved, merge compute, end-to-end lag and the engineering hours spent. Real numbers from your own data beat any vendor calculator.
There is no single right integration pattern for a whole company. The right unit of decision is the data flow: one source, its consumers, and the freshness and governance they need.
What Zero-ETL Hides (and Why That Matters)
Zero-ETL is genuinely useful. Removing a pipeline removes a class of failures, and for a single operational database feeding a single analytics store it is often the best choice. But the abstraction hides decisions you still own.
- Data modeling still happens. Replicated tables arrive in the source’s operational shape. Someone still has to build conformed, documented, tested models on top, so “zero-ETL” is really “zero-E-and-L.”
- Schema changes still propagate. A dropped or renamed column upstream will still affect reports and models downstream. You need contracts or at least change detection.
- Governance is not automatic. Sensitive columns replicate unless you exclude them. Masking, access policies and retention have to be configured on the target.
- Observability may be limited. You may see integration status but not row-level reconciliation or end-to-end lineage into downstream assets unless the platform emits it.
- Exit costs exist. Rebuilding twenty zero-ETL integrations on another platform is a migration project, not a configuration change.
A Scoring Model You Can Apply Per Flow
For each data flow, score the following from 1 (low) to 3 (high). The totals point toward a default, which you then sanity-check against constraints such as security policy and budget.
- Number of consumers for the same change stream (1 = one target, 3 = three or more).
- Need for in-flight processing such as masking, filtering or enrichment before landing.
- Portability requirement across clouds or platforms over the next three years.
- Latency sensitivity (seconds rather than minutes or hours).
- Team capacity to operate streaming infrastructure (inverted: 3 = strong platform team).
A total of 5 to 7 usually favors zero-ETL when an integration exists for your source and target pair, or a managed connector otherwise. A total of 8 to 11 suggests managed connectors, perhaps landing in an open table format to preserve flexibility. A total of 12 to 15 points to self-managed CDC with a durable event log. The model is deliberately simple; its value is forcing teams to articulate why a flow needs the more expensive option.
Running the assessment in practice
- List candidate flows. Start with the 15 to 30 flows that feed critical reports, operational processes or AI use cases, rather than every table in the estate.
- Interview consumers, not just source owners. Freshness and processing needs come from the people and systems that use the data. Source owners tell you what is feasible; consumers tell you what is necessary.
- Check feasibility constraints. Confirm whether a zero-ETL integration exists for the exact source version, region and target; whether the source permits replication privileges; and whether network paths from on-premises systems are approved.
- Score and decide. Apply the model, record the decision and the reasons in the flow registry, and note what would trigger a re-evaluation, such as a new consumer or a regional expansion.
- Review quarterly. Platform capabilities change quickly. A flow that needed custom CDC last year may have a native integration today, and vice versa when requirements grow.
Worked Example: One Company, Three Patterns
Imagine a logistics company standardized on AWS for analytics with a growing Databricks footprint for data science. It has five priority flows.
- Aurora PostgreSQL shipments database to Redshift for operational reporting. One consumer, little transformation, AWS-native. Score 6. Decision: zero-ETL integration, with column exclusions for personal data and dbt models on top.
- Salesforce and ServiceNow into the lakehouse. SaaS sources, analytics-only consumption, 30-minute freshness acceptable. Score 7. Decision: zero-ETL into S3 Tables where supported, landing in Iceberg so both Redshift and Databricks can read it.
- On-premises SQL Server ERP into Databricks. One primary consumer, needs SCD Type 2 history for finance. Score 8. Decision: managed connector in Lakeflow Connect, deployed through Terraform.
- Telematics events from a PostgreSQL ingestion service. Feeds the lakehouse, a real-time ETA service and an anomaly detector; needs filtering and enrichment. Score 13. Decision: Debezium into Kafka with Flink processing.
- Customer profile changes for the customer-service assistant. Needs masking before indexing and seconds-level freshness; two consumers. Score 12. Decision: outbox events captured with Debezium, processed and masked before reaching the search index.
The resulting landscape mixes three patterns, but every choice is explainable, documented, and revisitable. The common threads are open table formats at rest, consistent naming, a single lineage graph across all three patterns, and freshness SLOs that are monitored regardless of who runs the pipeline.
The team also writes a short exit plan for each pattern. For the zero-ETL flows, the plan notes which Debezium or managed connector would replace them if the company moved analytics off Redshift, and confirms that landing data in Iceberg keeps historical tables readable by other engines. For the self-managed flows, it documents who owns upgrades and what the fallback is if the streaming platform has an extended outage, such as temporarily switching the ETA service to a five-minute micro-batch. None of this is expensive to write down, and it turns a future migration from a crisis into a planned project.
Governance Across Mixed Patterns
Mixed integration estates fail when each pattern has its own governance island. Put four controls in place regardless of the mechanism:
- A flow registry: every integration listed with source, target, owner, pattern, freshness target and data classification.
- Contracts at the boundary: schema and semantics for important source tables or events, with change review before breaking changes ship.
- Unified lineage: emit or harvest lineage from zero-ETL, managed connectors and custom jobs into one catalog, ideally using an open standard such as OpenLineage.
- Cost visibility: tag integrations so that per-row connector charges, target compute and streaming infrastructure can be attributed to the domains that consume them.
Common Mistakes
- Choosing a single pattern for the whole estate because it simplifies procurement, then forcing ill-suited flows into it.
- Running self-managed CDC without a platform team, which turns a cost saving into an on-call burden.
- Ignoring volume-based pricing for high-churn tables until the first invoice arrives.
- Treating zero-ETL as “no work” and skipping modeling, testing and access controls.
- Building point-to-point integrations for a stream that three teams will eventually need.
Outlook
The direction of travel is clear: platforms will keep expanding native replication, independent vendors will keep moving up the stack toward transformation and semantic layers, as the June 2026 completion of the Fivetran and dbt Labs merger illustrates, and open table formats will make the landing zone less of a lock-in decision. That makes the integration pattern more interchangeable over time, provided you keep your contracts, lineage and storage open. Expect more teams to treat ingestion choices as reversible operational decisions rather than multi-year platform bets.
Conclusion
Zero-ETL, managed connectors and self-managed CDC are complements, not rivals. Zero-ETL removes pipelines for simple, single-destination flows; managed connectors cover the long tail of SaaS and database sources with little operational overhead; self-managed CDC earns its keep when many consumers, in-flight processing or portability matter. Decide per flow, document the reasoning, keep data at rest in open formats, and govern all three patterns through one registry and one lineage graph. That approach captures the convenience of the new platform features without surrendering control of your data architecture.
How Hanoi Technology Can Help
Hanoi Technology helps teams assess integration options flow by flow and then builds and runs the chosen zero-ETL, managed or custom CDC pipelines.
Further Reading
- AWS Glue zero-ETL integrations from DynamoDB and applications to S3 Tables – AWS
- Announcing AWS Glue zero-ETL for self-managed database sources – AWS
- SQL Server connector in Lakeflow Connect now generally available – Databricks
- Openflow connectors – Snowflake Documentation
- CDC Stream Processing: The Complete Guide – RisingWave
- Fivetran, dbt Labs complete merger to form data layer for AI – TechTarget