Debezium vs AWS DMS: Change Data Capture Comparison

Debezium and AWS Database Migration Service (DMS) are both widely used for change data capture, but they solve different problems. Debezium is an open-source, Kafka-native CDC platform built for streaming architectures. AWS DMS is a managed cloud service designed primarily for database migrations, with ongoing replication as a secondary use case.

What Is AWS DMS?

AWS Database Migration Service is a managed service that migrates databases to AWS with minimal downtime. For ongoing replication, DMS supports continuous data replication — capturing changes from a source and applying them to a target. Supported sources include Amazon RDS, Aurora, on-premises PostgreSQL/MySQL/Oracle/SQL Server, and more.

DMS uses task-based replication: you define a replication task specifying the source endpoint, target endpoint, and table mappings. DMS handles the log reading, transformation, and target writes transparently.

Key DMS characteristics:

• Fully managed — no infrastructure to operate
• Targets are typically other databases (RDS, Redshift, S3, DynamoDB)
• Tight integration with the AWS ecosystem
• Limited streaming semantics — primarily row-by-row apply rather than event streaming
• Pricing based on replication instance hours

What Is Debezium?

Debezium is an open-source CDC platform that runs as Kafka Connect source connectors. It reads database transaction logs and publishes structured change events to Kafka. Unlike DMS, Debezium is not a migration service — it is an event streaming platform for database changes.

Key Debezium characteristics:

• Open-source, runs anywhere (on-premises, any cloud)
• Publishes to Kafka — a durable, replayable event log
• Multiple consumers can read the same change events (fan-out)
• Full Debezium envelope: before, after, op, source, ts_ms
• Requires Kafka Connect infrastructure to operate
• Integrates with Schema Registry for Avro-encoded events

Step-by-Step: Debezium + RisingWave Pipeline

Step 1: Configure Debezium

Register a PostgreSQL connector:

{
  "name": "pg-connector",
  "config": {
    "connector.class": "io.debezium.connector.postgresql.PostgresConnector",
    "database.hostname": "postgres.internal",
    "database.port": "5432",
    "database.user": "debezium",
    "database.password": "secret",
    "database.dbname": "production",
    "database.server.name": "pg1",
    "slot.name": "rw_slot",
    "plugin.name": "pgoutput",
    "table.include.list": "public.orders",
    "topic.prefix": "pg1"
  }
}

Step 2: Connect RisingWave to Kafka

RisingWave is a PostgreSQL-compatible streaming database. Ingest the Debezium topic:

CREATE SOURCE orders_debezium
WITH (
    connector = 'kafka',
    topic = 'pg1.public.orders',
    properties.bootstrap.server = 'kafka:9092',
    scan.startup.mode = 'earliest'
) FORMAT DEBEZIUM ENCODE JSON;

Step 3: Build a Materialized View

CREATE MATERIALIZED VIEW orders_realtime AS
SELECT
    id,
    customer_id,
    status,
    amount,
    created_at
FROM orders_debezium;

Step 4: Run Analytics

CREATE MATERIALIZED VIEW orders_by_status AS
SELECT
    status,
    COUNT(*) AS count,
    SUM(amount) AS total_amount
FROM orders_realtime
GROUP BY status;

Step 5: Sink to Downstream Systems

CREATE SINK orders_analytics_sink
FROM orders_by_status
WITH (
    connector = 'kafka',
    topic = 'orders-analytics',
    properties.bootstrap.server = 'kafka:9092'
) FORMAT UPSERT ENCODE JSON
KEY ENCODE JSON (status);

Detailed Comparison

When to Choose Debezium

• You need to fan out changes to multiple consumers simultaneously (analytics, search, cache, notifications)
• You want a durable, replayable event log that consumers can replay from any offset
• You are building event-driven microservices that need to react to database changes
• You operate on-premises or in a multi-cloud environment without AWS lock-in
• You need to integrate with stream processing engines like RisingWave, Flink, or Spark Streaming

When to Choose AWS DMS

• You are migrating a database to AWS and need ongoing replication during the cutover window
• Your target is an AWS service (RDS, Aurora, Redshift, S3) and you want minimal setup
• Your team lacks Kafka expertise and prefers a managed point-and-click interface
• Your CDC requirements are simple: replicate these tables to that database
• Cost predictability is important and you can estimate replication instance hours

FAQ

Can I use AWS DMS to feed RisingWave? Not directly via native Debezium format. However, you can configure DMS to write to Amazon Kinesis or Amazon MSK (managed Kafka), and RisingWave can read from Kinesis or Kafka. This adds architectural complexity compared to using Debezium directly.

Is Debezium free? Debezium is open-source (Apache 2.0 license). You pay for the infrastructure it runs on — Kafka Connect workers and Kafka brokers. Confluent offers a managed Debezium-compatible service. Redpanda and Aiven offer managed Kafka with Debezium connectors.

Can both tools capture deletes? Yes. Debezium captures deletes as op=d events with the before field populated. AWS DMS can apply deletes to the target database. Debezium's approach is more flexible — the delete event is a first-class record in Kafka that any consumer can process.

Key Takeaways

• Debezium is a streaming-first, open-source CDC platform; AWS DMS is a managed migration service with replication capabilities
• Debezium publishes to Kafka with a rich event envelope (before, after, op, ts_ms), enabling fan-out and replay
• RisingWave integrates natively with Debezium via FORMAT DEBEZIUM ENCODE JSON on Kafka sources
• Choose Debezium for streaming architectures, multi-consumer fan-out, and vendor-neutral deployments
• Choose AWS DMS for simple AWS-to-AWS migrations with minimal operational overhead

Get started | Slack