What Nobody Explains About Debezium in 2026 (But Should)

Deployment models and the Kafka question

One of the most common questions during CDC evaluations is whether Debezium requires Apache Kafka. This characterization reflects earlier deployment patterns. Debezium is a Change Data Capture platform, and Apache Kafka Connect is one deployment model, not a requirement.

For many teams, Kafka Connect remains the preferred deployment model, not because it is the only option, but because of the capabilities it provides.

Setup complexity and getting started

Some evaluation articles describe getting Debezium running in production as a multi-day or multi-week effort requiring extensive component configuration. Historically, Kafka Connect deployments did involve more moving parts, and that shaped perceptions. The landscape looks different today, particularly with Debezium Server.

Here is what a basic Debezium Server setup actually involves. We’ll use MySQL as the example, since it also requires schema history storage, which makes it a good illustration of a realistic configuration.

docker run -d --name debezium -p 8080:8080 \
  -v debezium-data:/debezium/data \
  -e DEBEZIUM_SOURCE_CONNECTOR_CLASS=io.debezium.connector.mysql.MySqlConnector \
  -e DEBEZIUM_SOURCE_DATABASE_HOSTNAME=your-db-host \
  -e DEBEZIUM_SOURCE_DATABASE_PORT=3306 \
  -e DEBEZIUM_SOURCE_DATABASE_USER=debezium \
  -e DEBEZIUM_SOURCE_DATABASE_PASSWORD=secret \
  -e DEBEZIUM_SOURCE_TOPIC_PREFIX=myapp \
  -e DEBEZIUM_SOURCE_OFFSET_STORAGE=io.debezium.storage.file.history.FileOffsetBackingStore \
  -e DEBEZIUM_SOURCE_OFFSET_STORAGE_FILE_FILENAME=/debezium/data/offsets.dat \
  -e DEBEZIUM_SOURCE_SCHEMA_HISTORY_INTERNAL=io.debezium.storage.file.history.FileSchemaHistory \
  -e DEBEZIUM_SOURCE_SCHEMA_HISTORY_INTERNAL_FILE_FILENAME=/debezium/data/schema-history.dat \
  -e DEBEZIUM_SINK_TYPE=kinesis \
  -e DEBEZIUM_SINK_KINESIS_REGION=us-east-1 \
  quay.io/debezium/server:3.5

Or, if you prefer docker-compose, a minimal docker-compose.yml for the same setup looks like this:

services:
  debezium:
    image: quay.io/debezium/server:3.5
    ports:
      - "8080:8080"
    volumes:
      - ./conf:/debezium/conf
      - debezium-data:/debezium/data
    environment:
      - DEBEZIUM_SOURCE_CONNECTOR_CLASS=io.debezium.connector.mysql.MySqlConnector
      - DEBEZIUM_SOURCE_DATABASE_HOSTNAME=your-db-host
      - DEBEZIUM_SOURCE_DATABASE_PORT=3306
      - DEBEZIUM_SOURCE_DATABASE_USER=debezium
      - DEBEZIUM_SOURCE_DATABASE_PASSWORD=secret
      - DEBEZIUM_SOURCE_TOPIC_PREFIX=myapp
      - DEBEZIUM_SOURCE_OFFSET_STORAGE=io.debezium.storage.file.history.FileOffsetBackingStore
      - DEBEZIUM_SOURCE_OFFSET_STORAGE_FILE_FILENAME=/debezium/data/offsets.dat
      - DEBEZIUM_SOURCE_SCHEMA_HISTORY_INTERNAL=io.debezium.storage.file.history.FileSchemaHistory
      - DEBEZIUM_SOURCE_SCHEMA_HISTORY_INTERNAL_FILE_FILENAME=/debezium/data/schema-history.dat
      - DEBEZIUM_SINK_TYPE=kinesis
      - DEBEZIUM_SINK_KINESIS_REGION=us-east-1
volumes:
  debezium-data:

That is the entire deployment: configure your source connection and your sink destination, and you have a complete CDC pipeline with one unit of deployment.

An important distinction: configuring your database correctly, enabling logical replication on PostgreSQL, configuring the correct binlog_format on MySQL, or setting up the LogMiner permissions on Oracle, does require careful attention. These steps are not unique to Debezium; any CDC tool that reads from transaction logs requires the same database-level setup. Debezium’s documentation covers each database thoroughly.

Teams often encounter setup complexity that is inherent to CDC itself rather than specific to Debezium. Distinguishing between the two is important when comparing tools.

There is also a deployment path worth highlighting: embedding Debezium directly into your application.

<dependency>
  <groupId>io.debezium.quarkus</groupId>
  <artifactId>quarkus-debezium-mysql</artifactId>
</dependency>

Transformation capabilities

A common question in CDC evaluations is whether Debezium provides sufficient transformation support. The answer depends on what your use case requires and how you think about where transformations belong in your architecture.

Debezium is designed as a CDC solution, not a general-purpose transformation engine. This is a deliberate architectural choice: do one thing extremely well, and compose cleanly with tools that handle the next stage. Some CDC tools take the opposite approach, building transformation capabilities directly into the platform. Both approaches have merit, and which one fits better depends on your team’s architecture and preferences.

For transformation needs within the CDC layer, Debezium’s Single Message Transforms (SMTs) cover significant ground out of the box:

Debezium also supports any Kafka Connect-compatible SMT, not just its own. The broader Kafka ecosystem of transformations is available across all Debezium deployment options: Debezium Server, the embedded Engine, the Quarkus Extensions, and every other part of the portfolio. This gives you access to a wide library of existing community transforms regardless of how you deploy.

For teams that need heavier in-flight processing, such as complex joins, aggregations, or conditional routing across multiple change event streams, the natural approach is integrating Debezium with a stream processor like Apache Flink or Kafka Streams. These tools are purpose-built for complex event processing, and Debezium’s Kafka Connect deployment makes that integration straightforward.

For teams using Debezium’s embedded deployment options, such as the Quarkus Extensions, Spring Integration, or the Debezium Engine directly, transformation capabilities are effectively unlimited. You have the full power of your programming language available to process, enrich, or transform change events however your use case demands, with no constraints imposed by a plugin API.

Monitoring and observability

Debezium does not include a built-in web interface for monitoring connectors. This is a real gap for teams that expect a turnkey monitoring experience, and it is worth acknowledging directly.

What Debezium does provide is comprehensive metrics exposure. Debezium exposes a rich set of JMX metrics covering connector status, transaction log position, event counts, processing rates, and lag. When paired with Prometheus JMX Exporter and Grafana, you get production-grade observability with dashboards the community has built and shared. The Debezium monitoring example provides a ready-to-run setup with Prometheus and Grafana pre-configured, so you can see what this looks like in practice.

Setting up this observability stack is a real step. The distinction between "no monitoring" and "requires a standard observability stack" is important. The Prometheus and Grafana combination is the industry standard for monitoring Java-based distributed systems, and Debezium integrates naturally with that ecosystem. Teams already running this stack will find Debezium metrics straightforward to add. Teams without an existing observability stack will need to account for that setup.

For teams running Debezium on Kubernetes, the Debezium Operator integrates with standard Kubernetes observability tooling, and connector health is surfaced through standard resource status fields.

This is also an area where the project is actively investing. Debezium Platform is gaining native metrics and monitoring support, built in rather than bolted on, so that operators will have first-class observability with the ability for Debezium to provide the entire stack for you. That work is in progress and reflects the project’s commitment to reducing operational friction.

When Debezium may not be the best fit

Choosing the right CDC tool means understanding where each option’s strengths align with your team’s needs. Debezium is not the best fit for every situation, and we would rather be direct about that than leave you to discover it after investing time in an evaluation.

You want a fully managed, end-to-end SaaS workflow. Debezium is an open-source project, and running it yourself means you are responsible for operations, monitoring, and upgrades. Debezium Platform is actively reducing that operational burden, and several vendors offer managed CDC services built on Debezium, so managed options do exist. But if your primary requirement is a turnkey SaaS experience with no operational responsibility, tools that are built as managed services from the ground up may be a more natural fit.

You prefer a tightly integrated transformation and runtime platform. Some CDC tools bundle transformation, orchestration, and delivery into a single integrated platform. If your team values that kind of opinionated, all-in-one experience over the flexibility of composing separate tools, those platforms may align better with your workflow.

Your team has no existing JVM or distributed systems operational experience. Debezium runs on the Java Virtual Machine (JVM). PyDebezium makes it possible to consume change events from Python applications, and the Debezium Quarkus Extensions provide GraalVM native compilation, removing the need to install a JVM at runtime.

Even so, the underlying engine is a JVM-based system. When something goes wrong in production, and in any distributed system something eventually will, troubleshooting and bug reporting will benefit from at least some familiarity with that ecosystem. If your operations team has none, there will be a learning curve.

You have small-scale CDC needs where deployment simplicity outweighs flexibility. For straightforward, small-scale CDC scenarios where you don’t need Debezium’s range of deployment options, database support, or ecosystem integrations, a simpler tool with fewer choices may get you to production faster.

How Debezium fits modern CDC architectures

Debezium’s design philosophy prioritizes composability, openness, and integration into existing data ecosystems rather than providing a single tightly coupled platform. This means teams assemble their CDC pipelines from components that fit their architecture, choosing their deployment model, their messaging infrastructure, their transformation layer, and their observability stack.

That composability comes with tradeoffs. It requires more architectural decisions upfront compared to an opinionated platform, and teams need to be comfortable with that responsibility. For organizations that value flexibility, ecosystem portability, and the ability to evolve their architecture independently, it is a significant advantage.

Today, Debezium offers a range of deployment options to fit different architectures and team needs:

Transformations are handled by a rich set of SMTs out of the box, including AI-powered embeddings, and any Kafka Connect-compatible SMT works across all deployment options. Monitoring integrates with standard JVM observability tooling, and Debezium Platform is actively investing in built-in observability.

Debezium has been in active development since 2015, is battle-tested in production across a wide range of industries, and is backed by an engaged open-source community. That maturity matters when you’re choosing infrastructure your data pipelines will depend on.

Different organizations value different tradeoffs, and evaluations should reflect the capabilities and deployment models available today rather than assumptions carried over from earlier generations of CDC tooling. We hope this gives you a more complete and current picture for your evaluation.

If you’d like to try Debezium yourself, the Debezium Server quickstart is the fastest way to see it in action, and our community is ready to help you with the first steps.

Have questions or want to discuss? Join the conversation in the Debezium community.