Airbyte or Debezium for change data capture: when to choose each
Choose Airbyte when the goal is scheduled ELT that lands operational data in a warehouse, lake or AI application, and the team wants a connector catalog, a UI and a Kubernetes-deployed platform. Its core is under the Elastic License 2.0, so review that license with counsel if you plan to offer the platform to third parties. Choose *Debezium*, which is Apache 2.0, when the need is a stream of row-level change events from a database that downstream systems consume as they happen. Debezium can run on Kafka Connect, as Debezium Server without Kafka, or as an embedded engine inside an application. The decision turns on four questions: how fresh the data must be, whether Apache Kafka already runs in your environment, which source database types you must read from, and whether your engineers can operate a streaming pipeline.
Start with freshness. If dashboards or nightly reconciliations tolerate batch windows, Airbyte's scheduled syncs keep the operating model simpler. If consumers need each committed change as an event, a CDC pipeline is the better fit. Next, check Kafka. A team that already runs Kafka and Kafka Connect can add Debezium connectors to existing infrastructure, while a team without Kafka may prefer Debezium Server, which the Debezium documentation describes as streaming change events without Apache Kafka. Then confirm source coverage. Debezium's source connectors cover MySQL, MariaDB, MongoDB, PostgreSQL, Oracle, SQL Server and Db2, plus Cassandra, and several others are marked incubating, so verify your exact database version and the connector's status in the Debezium connectors documentation before you commit.
Plan for skills and recurring work. Debezium pipelines require engineers who understand database logs, offsets, schema changes and the failure modes of Kafka Connect or an embedded runtime, and that expertise is ongoing rather than a one-time setup. Airbyte shifts more of the work to configuration and connector upkeep, but it still needs a Kubernetes platform team and a plan for connector versions. Ask any implementation partner for a written scope that covers source permissions, replication settings, retention of change logs, monitoring of lag and a tested recovery path for each source before go-live.
Which scenario fits Airbyte and which fits Debezium
This table maps common change data capture and replication scenarios to the option that usually fits better, with the condition that would reverse the choice. Read each row as a starting point, then check the conditions against your own sources, latency expectations and team skills before deciding.
| Scenario | Better fit and why | When the other option wins |
|---|---|---|
| Nightly or periodic warehouse loads | Airbyte. Scheduled batch syncs from databases, files and SaaS APIs into a warehouse or lake fit its ELT model without running a streaming stack. | Debezium wins if the same tables must feed downstream systems continuously and a periodic snapshot no longer meets the freshness the business needs. |
| SaaS API sources (CRM, billing, ticketing) | Airbyte. Its connector catalog is built for API pagination, authentication and incremental cursors. Debezium reads database logs, so it does not reach most SaaS APIs. | Debezium wins only when the SaaS vendor exposes its data through a database you can read at the log level, which is uncommon. Confirm the source type first. |
| A team already running Kafka and Kafka Connect | Debezium, deployed as Kafka Connect source connectors, usually fits because the team already operates the brokers, monitoring and connector REST management. | Airbyte wins if the main need is warehouse delivery with a UI and little Kafka operating work, since Airbyte does not require your Kafka estate. |
| An application that needs change events inside its own code | Debezium, through the embedded connector engine. It delivers row-level events directly to the application without a separate broker layer. | Airbyte wins only when the consumer is an analytics store and not application logic. Event-driven application code is outside its batch-style model. |
| Streaming to non-Kafka targets without a Kafka cluster | Debezium Server, which streams change events to messaging and storage systems without Apache Kafka. Confirm the sink types you need are supported. | Airbyte wins if the target is a warehouse or lake and the team wants managed sync schedules rather than operating a streaming application. |
| Mixed estate with OLTP databases and SaaS sources | Often both. Debezium feeds low-latency database changes into an event path, while Airbyte loads SaaS and file sources on a schedule. Keep ownership and schemas documented per pipeline. | A single platform is simpler if one team owns everything and the latency requirement is loose enough for batch syncs across all sources. |
| Limited data engineering staff and no Kafka skills | Airbyte, because its deployment is a Kubernetes install with a UI and documented Helm values, which is a smaller skill step than a streaming stack. | Debezium becomes practical once the team gains Kafka or streaming operations skills or buys that support. Ask DeployOpen or your own staff to confirm the skill gap before choosing. |
How Airbyte syncs and Debezium change events are built
Airbyte and Debezium both move data out of source systems, but they differ in what runs the pipeline, where progress is recorded, and who gets paged when something stops. The cards below walk through the deployment shapes on each side so you can check which operating model your team can actually support.
Airbyte platform on Kubernetes
Airbyte is built to run in a Kubernetes cluster, and the project highly recommends installing it with Helm and its documented chart values. Your team owns the cluster, the database Airbyte uses for its own state, storage for logs and the upgrade cadence. Sync progress is tracked by the platform, so a failed job is retried or surfaced in the UI rather than resumed from a log position you manage yourself. Confirm which chart version and values your platform team will standardize on before committing.
Single-machine setups with abctl and Docker
For evaluation, local work or a small single-machine install, Airbyte documents abctl and Docker. These paths are useful for testing connectors and sync schedules, but they are not a substitute for a clustered production layout. Ask whether the single host has backups, monitoring and a documented recovery path, since the platform's state lives on that machine. Treat this as a proving ground unless your scope explicitly accepts one host as the production footprint.
Debezium connectors in Kafka Connect
The main Debezium deployment reuses Kafka and Kafka Connect for durability and fault tolerance, and each connector monitors one upstream database server. Your team must run and secure the Kafka brokers, the Connect workers and the topics that carry change events, so the operating load is closer to a streaming platform than to a sync job. A connector restart is a Connect task restart that resumes from the offsets stored in Kafka, which is why broker health and retention settings matter. Confirm who holds on-call for the brokers.
Debezium Server without Kafka
Debezium Server is a ready-to-use application that streams change events from a source database to messaging and storage systems without requiring Apache Kafka. You remove the broker layer from your operating scope, but you take on the job of choosing a sink and confirming it meets your durability and ordering needs. Offsets and delivery guarantees depend on the sink and the server configuration, so ask the vendor and test a connector restart against your target before relying on it. This option suits teams that want change events in a target system without running a Kafka estate.
Embedded engine inside the application
Applications that do not need Kafka can use Debezium's embedded connector engine to receive change events directly inside the application process. Your application team then owns offset storage, error handling and restart behavior, because no separate platform holds that state for you. This moves the work into code that must be tested, versioned and deployed with the service. It fits a narrow case where one application consumes changes, and it is a poor fit for a shared data platform that many consumers depend on.
Who runs the brokers and where offsets live
The central operating question is where progress is recorded. In Airbyte, the platform tracks sync state for batch jobs. In Kafka Connect, offsets sit in Kafka topics, and in Debezium Server or the embedded engine they sit in the configured store. Ask each vendor where offsets are persisted, how they are backed up, and what happens after a database failover, because a lost or stale offset can mean replayed or skipped changes. Put this question into your proof of concept before you pick a deployment shape.
Latency, sources and infrastructure side by side
This table sets Airbyte's batch-style ELT sync against Debezium's row-level change events across delivery model, sources, destinations, footprint, deployment and licensing. Read each row as a question to answer for your own source systems, because the right choice depends on how fresh the data must be and which databases you run.
| Capability | Airbyte | Debezium |
|---|---|---|
| Delivery model | Batch-style ELT syncs that read source data on a schedule and load it into a destination | Streams an event for each committed row-level change from the source database log |
| Latency | Set by sync frequency and connector behavior; measure end-to-end lag in your own environment | Set by connector lag and downstream consumers; measure end-to-end lag in your own environment |
| Source coverage | API, database and file sources through its connector catalog; confirm each connector for your source version | MySQL, MariaDB, MongoDB, PostgreSQL, Oracle, SQL Server, Db2 and Cassandra; several others such as Vitess, Spanner, Informix and CockroachDB are marked incubating |
| Sinks and destinations | Warehouses, lakes and AI applications from its connector catalog | Kafka topics through Kafka Connect, messaging and storage systems through Debezium Server, JDBC and MongoDB sinks, or the application itself through the embedded engine |
| Infrastructure footprint | Kubernetes deployment, recommended with Helm; abctl and Docker for single-machine setups | Kafka and Kafka Connect in the standard path; Debezium Server or the embedded engine avoid Kafka |
| Deployment method | Helm chart on Kubernetes, with documented chart values | Kafka Connect connectors, Debezium Server application, or a library inside your application |
| Licensing | Core platform under Elastic License 2.0; connectors under MIT | Apache 2.0 |
| Confirm before choosing | Connector maturity for your source and destination, and whether your edition covers the features you need | Connector maturity for your source version, plus the operating model for Kafka or Debezium Server |
What ELv2 and Apache 2.0 mean for your deployment
Airbyte Core, the platform itself, has been under the Elastic License 2.0 (ELv2) since version 0.30.0, released September 27, 2021. Under ELv2, your organization may use Airbyte commercially for internal operations, build applications powered by Airbyte data, and use it for client work as a data agency. The license does not allow you to host Airbyte and sell it as an ELT tool, or to expose its UI or API directly to your customers. The points below cover what this means in practice.
- Internal use is permitted: Running Airbyte to move data for your own analytics, reporting and AI applications falls within the internal operations grant.
- Client work is permitted: A data agency can deploy and operate Airbyte for clients, but must not resell hosted Airbyte as a product.
- Managed service is barred: Offering Airbyte to third parties as a hosted or managed service is the restriction most likely to affect a SaaS vendor.
- License key functionality is protected: The license also prohibits circumventing license key functionality, so review any licensed feature before enabling it.
- Editions are documented: Airbyte documents Core and Enterprise Flex editions, with the deployment guide covering the open Core version for self-managed installations. Confirm with Airbyte which features sit in each edition and what they cost.
Check with counsel whether your planned use, especially any customer-facing exposure, fits the ELv2 terms.
Debezium is an open source change data capture platform licensed under Apache 2.0. Apache 2.0 is a permissive license that allows commercial use, modification, redistribution and hosting as a service without the managed-service restriction found in ELv2. Your organization can run Debezium internally, embed it in products and offer it to third parties, subject to the license's notice and attribution terms. Debezium's license does not change the operating dependencies, which are separate from the license decision.
- Permissive terms: Apache 2.0 places no restriction on hosting Debezium for customers, which matters if you are a platform vendor.
- Kafka is a separate dependency: Debezium reuses Kafka and Kafka Connect for durability and fault tolerance, so Kafka carries its own license and operating commitments.
- Debezium Server runs without Kafka: Debezium Server streams change events to messaging and storage systems without requiring Apache Kafka.
- Embedded engine is an option: Applications that do not need Kafka can use the embedded connector engine to receive change events inside the application.
- Dependencies need their own review: Each connector and any sink you add should be checked for its own license before you distribute a combined stack.
Confirm that the Apache 2.0 terms fit your redistribution plans and that every component in your chosen deployment is covered by a license you have reviewed.
Airbyte's connectors and its Connector Development Kit (CDK) are licensed under the MIT license, which is separate from the ELv2 terms on the Airbyte Core platform. Airbyte states that its own connectors remain open source and that contributors who develop their own connectors can choose whichever license they prefer. This split matters when you plan to write custom connectors, because the code you build can follow terms that differ from the platform that runs it.
- Connectors are MIT: Airbyte's connectors and the CDK can be reused under MIT terms, which are among the most permissive open source licenses.
- Custom connectors can use your own license: Contributors who build their own connectors may choose the license for that code.
- Platform license still applies: Running MIT connectors inside Airbyte Core still means the ELv2 restrictions on hosting the platform apply.
- Debezium connectors are Apache 2.0: Debezium's source connectors fall under the Apache 2.0 license of the project as a whole.
- Track upstream changes: Connector versions and licenses can change between releases, so record the version and license of each connector you deploy.
Before you commit to a connector set, confirm the license of each connector in your environment and record it in your software inventory.
What drives the running cost of each
Running Airbyte and a Debezium pipeline both cost more than the software line on a quote. The main differences come from the platform you operate, the skills your team needs to keep it healthy and the ongoing work of upgrades, lag monitoring and schema changes. Use these cards to shape the questions you put to any implementation partner or vendor.
Platform footprint to run
Airbyte is built to be deployed into a Kubernetes cluster and is best installed with Helm and its documented chart values, so the cluster itself becomes a recurring cost you own. Debezium changes shape depending on the mode: Kafka brokers and Kafka Connect workers for the Kafka route, or a lighter Debezium Server or embedded engine when Kafka is not wanted. Ask which components are counted in your estimate, including storage, backups and the number of environments you must keep.
Skills to operate streaming
A batch ELT sync runs on a schedule and fails in ways a data team can usually retry. A CDC pipeline runs continuously, so it needs people who understand database logs, replication slots, offsets, Kafka partitions and connector restarts. This skill gap is often the largest recurring cost, because it is paid in on-call time and training rather than in licenses. Ask who will carry the pager and whether your team already runs Kafka in production.
Upgrade and patch effort
Each component in a CDC stack has its own release train: the Airbyte chart and platform, Debezium connectors, and Kafka or Debezium Server underneath. Debezium 3.7 is the latest stable version listed on debezium.io, so a stack built today will need planned moves across versions. Ask the partner to price upgrades as a recurring scope item, covering test environments, rollback plans and connector compatibility checks.
Airbyte Cloud or Enterprise options
Airbyte Cloud and the Enterprise Flex edition shift part of the operating work to the vendor, but they change the licensing and data path picture. Under the Elastic License 2.0, self-hosting Core for internal operations is permitted, while hosting Airbyte as a service for third parties is not. Ask which edition the quote assumes, what the subscription covers and whether CDC sources are supported in that edition.
Monitoring lag and schema drift
Streaming pipelines need alerts on replication lag, connector state and the growth of the source transaction log, because a stalled connector can fill disks on the source database. Schema changes in the source, such as a new column or a renamed table, must be propagated to consumers without breaking them. Ask for the monitoring stack, the lag thresholds that trigger a page and the procedure for re-snapshotting a table after a failure.
Where Airbyte and Debezium projects usually run long
Airbyte projects tend to run long in the setup work around the platform rather than in the first sync. Plan for deployment sizing on Kubernetes, where Airbyte recommends installing with Helm and its documented chart values, and for the connector configuration and credential handling that follows: each source needs a read-only database account, network access from the cluster, and a decision on where secrets live. Sync scheduling is the next place time disappears. Teams often start with frequent full refreshes, then discover that incremental modes depend on cursor fields that were never validated against real update patterns. Confirm with your own source owners which columns change reliably before you commit to a schedule, and confirm sizing against your data volumes in a test environment.
Debezium projects run long at the database and the consumer, not at the connector. On the database side, the work is enabling and retaining the transaction log correctly, granting the replication privileges the connector needs, and agreeing with the DBA team on log retention so that a paused consumer does not leave the source short of log space. Initial snapshots are the most common surprise. A snapshot of a large table can hold locks, consume I/O, and take far longer than the team expected, so test snapshot duration on a copy of production before the cutover date. Operating the transport is the next layer: a Kafka Connect cluster with its own monitoring, or Debezium Server without Kafka, each needs an owner for upgrades and restarts.
The hardest problems appear downstream. Schema evolution, deletes, and ordering all reach the consumer, and a sink that treats every event as an upsert will eventually diverge from the source. Decide early how column additions and type changes are applied, whether deletes become tombstones or soft-delete flags, and how out-of-order or replayed events are handled per key. Name one team that owns the sink, its tables, and its reconciliation checks. If that ownership sits with nobody, the pipeline works until the first incident and then stalls while teams argue about whose data is wrong. Ask your vendors and internal teams to write those decisions down before build begins.
Moving from Airbyte syncs to Debezium CDC, or back
This sequence moves a set of tables between batch Airbyte syncs and Debezium change streams without losing rows, deletes or consumer trust, and it ends with a clear record of what each side owns.
Inventory sources, sinks and consumers
The data platform lead lists every source table, every destination (warehouse table, lake path, topic or application database), and every downstream consumer that reads from it. For each Airbyte connection, record the sync mode, the cursor or primary key used for incremental loads, the schedule, and how deletes currently reach the destination. This inventory shows which pipelines are simple to swap and which carry hidden dependencies. It is done when every connection has a row in a shared sheet that the source owner and the sink owner have both signed off on.
Confirm database log settings and permissions
The database administrator checks whether each source database has the change log enabled and retained long enough for the connector to read it, and whether a dedicated replication account has the privileges the chosen Debezium connector documents. Debezium's connector documentation lists the requirements for each source system (MySQL, PostgreSQL, SQL Server, Oracle and others), so confirm the exact settings against the version your database runs. Also confirm whether Airbyte reads from the same source with its own account, so the two do not contend for limits. The step is done when a test login can read the log position and a written checklist shows each setting as verified.
Choose the Debezium runtime for each sink
The platform engineer decides how change events will leave the database. Kafka Connect fits teams that already run Kafka and need durable, replayable topics. Debezium Server fits teams that want to stream to other messaging or storage systems without Kafka. The embedded engine fits a single application that consumes changes in-process. Note that Debezium reuses Kafka and Kafka Connect for durability, so a Kafka-free design changes where offsets and recovery live. The step is done when a one-page decision record names the runtime for each pipeline and the team that operates it.
Run the new pipeline alongside the old sync
Deploy the Debezium pipeline to write to a parallel target, such as a new schema or a shadow table, while the Airbyte connection keeps writing to the production target. Let both run through at least one full business cycle, with the length set by your own change volume and not by any figure in this guide. Check that the initial snapshot completes and that streaming changes arrive in order after it. The step is done when the snapshot has finished and the parallel target is receiving changes with no unexplained gaps in the logs.
Reconcile counts, keys and deletes
The data quality owner compares row counts, primary key sets and aggregate checksums between the Airbyte target and the Debezium target for the same window. Pay particular attention to deletes, because a batch sync that does not propagate removals and a change stream that emits delete events will disagree in ways that counts alone can miss. Record each mismatch with its cause, such as a sync lag, a transaction boundary or a schema change. The step is done when every table has a reconciliation report with zero unexplained differences, and the owner signs it.
Cut over consumers in sink-specific order
The data platform lead moves consumers from the old target to the new one. The order depends on the sink. For a warehouse with downstream models, switch the models first and keep the old table available for rollback. For Kafka topics, move consumer groups one at a time and confirm their committed offsets advance. For embedded consumers, deploy the application change behind a feature flag. Confirm each vendor's documentation for the sink you use before you set the order. The step is done when every consumer reads from the new target and a rollback path has been tested.
Retire the old sync and document the handover
After a period of stable operation agreed by the owners, disable the Airbyte connection, remove its schedule and credentials, and archive its configuration. Keep the Airbyte connection definition and the old target table until the rollback window closes. Record the new Debezium connector configuration, offsets location, monitoring and alerting in the runbook. The step is done when the old connection is disabled, its credentials are revoked, and the runbook names an owner for each Debezium component.
What buyers ask before choosing or hiring help for CDC
How much effort does it take to run Airbyte or Debezium ourselves?
Both need a team that can operate infrastructure, but the work differs. Airbyte is built to be deployed into a Kubernetes cluster, and Airbyte highly recommends deploying with Helm and its documented chart values, so your platform team owns the cluster, upgrades and secrets. Debezium runs as connectors on Kafka Connect, as Debezium Server, or as an embedded engine inside an application, so the effort depends on which runtime you pick and whether you already operate Kafka. Ask each vendor or your own engineers to size the run book for your chosen topology, including upgrades, offset handling and monitoring, before you commit.
Do we need a consultant or implementation partner for CDC?
Not always. A small team with database and platform experience can run a single pipeline without outside help, while a regulated estate with many sources, strict change windows or audit evidence needs often benefits from one. DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. Ask whether the partner would also operate the pipelines after go-live, since ongoing support is available as a retainer.
What does an implementation engagement include?
A typical CDC engagement covers source assessment, database preparation such as enabling the replication features each source needs, connector or pipeline configuration, target loading, security hardening, backup and recovery, runbooks and knowledge transfer. Whether it also covers testing, compliance evidence or custom connectors depends on the written scope. Ask for a list of deliverables tied to each source and target, and confirm what is excluded, such as changes to source applications or downstream data models.
What does the work need from our database, data and platform teams?
Database administrators must grant replication privileges, approve log retention settings and confirm that the source can sustain change capture load. Data engineers define target schemas, handle schema changes and validate that downstream consumers read events correctly. Platform engineers run the Kubernetes cluster, Kafka or the runtime that hosts the connectors, plus secrets, networking and monitoring. If one of these groups is missing, the project usually stalls at the first access request, so confirm named owners for each role before the schedule is set.
How long does a CDC project take, and what drives the timeline?
The timeline depends on the number of sources, their database engines and versions, the state of their replication settings, the target platforms, the change approval process and how many schema changes are expected during the project. Scope agreed in writing sets the schedule, so no general duration applies. Ask for a timeline split into discovery, build, test and cutover, and identify which steps wait on your change approvals or access requests.
Does Airbyte's Elastic License 2.0 affect how we use it?
For most internal data teams, no. The Elastic License 2.0 covering Airbyte Core allows commercial use for internal operations, building applications powered by Airbyte data, and client work as a data agency. It prohibits hosting and selling Airbyte as an ELT tool or exposing its UI or API directly to customers, and it forbids circumventing license key functionality. Airbyte connectors and the Connector Development Kit are MIT licensed. If you plan to offer pipelines as a service to third parties, have counsel review the license FAQ against your product plan.
Can Debezium work without Kafka?
Yes. Debezium Server is a ready-to-use application that streams change events from a source database to messaging and storage systems without requiring Apache Kafka. Applications that do not need Kafka can also use Debezium's embedded connector engine to receive change events directly inside the application. Kafka Connect remains the default path, which gives durability and fault tolerance through Kafka. Choose based on your downstream consumers and the operational skills you already have, and confirm which sinks your chosen runtime supports.
How do we compare fixed-scope written proposals?
Compare proposals line by line against the same scope: the sources and targets covered, the deliverables, the environments, the test and cutover steps, the handover items and the exclusions. Check who performs each task, what access they need and whether support or retainer terms follow go-live. Ask each bidder to state assumptions about source versions and change windows, because those assumptions drive most differences in effort. A quote is only comparable when every bidder priced the same written scope.
How DeployOpen helps choose, implement or migrate CDC
DeployOpen plans and implements self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, so the choice between Airbyte batch syncs and Debezium change events is made against your sources, latency needs and infrastructure. Engagements are scoped in writing before work starts and documented for your team to run.
How we scope
- Inventory source databases, versions, change log settings and the downstream systems that need row-level changes
- Agree in writing which latency targets, delivery paths and warehouse or messaging destinations are in scope
- Define whether Kafka, Debezium Server or the embedded engine fits your operating model, and record the reasons
- Engagements are fixed-scope, with deliverables and timelines agreed before any work begins
How we build
- Deploy the chosen pipeline stack in your environment, with Helm-based Airbyte or Debezium connectors as the scope dictates
- Configure source permissions, replication slots or binlog access and destination credentials under your access controls
- Test initial snapshots, incremental change capture, schema changes and restart behavior against agreed test cases
- Wire monitoring and alerting for connector lag and failed syncs into the tools your team already uses
How we hand over
- Document the architecture, data flows, configuration and runbooks for each connector and destination
- Walk your operators through failure recovery, connector upgrades and offset or state handling
- Provide evidence of configuration and test results that your auditors or internal reviewers can examine
- Confirm licensing terms for your intended internal use with your legal team before production rollout
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- Plan connector and platform upgrades against the release support windows you confirm with each vendor
- Review source database changes that can affect capture, such as schema or version changes, before they reach production
- Agree support scope, response expectations and escalation paths in writing as part of the retainer
