Debezium vs AWS Database Migration Service (DMS) for CDC

AWS DMS and Debezium both do CDC, but they solve different problems. DMS is a managed migration service optimized for one-time database moves and continuous replication to AWS targets. Debezium is a change capture layer for event streaming. RisingWave is a third option: it captures changes and processes them in SQL without Kafka or managed migration infrastructure. Which one fits depends on your team's AWS footprint, target system, and operational tolerance.

What AWS DMS Actually Does

AWS DMS (Database Migration Service) was built primarily to migrate databases to AWS. Its CDC mode is an extension of that — it captures changes from a source and replicates them to a target continuously after the initial load.

DMS supports a wide range of sources (Oracle, SQL Server, MySQL, PostgreSQL, MongoDB, and others) and targets (RDS, Aurora, S3, Redshift, Kinesis, Kafka, DynamoDB). The key constraint: DMS targets are almost all AWS services. If your target is not on AWS, DMS is the wrong tool.

DMS is fully managed. You do not run agents or Kafka Connect workers. You configure tasks in the AWS console or via CloudFormation, and AWS handles the infrastructure.

What Debezium Does

Debezium is a CDC layer that publishes database changes to Kafka topics. It requires Kafka and Kafka Connect to run. Everything downstream of Kafka is your responsibility: consumers, processors, target writers.

The strength is flexibility. Debezium changes land in Kafka, and any number of consumers can read them: Flink, Spark, custom applications, Kafka Connect sink connectors to any target. No AWS lock-in.

The cost: you operate Kafka. Even managed Kafka (Confluent Cloud, MSK) adds latency, cost, and operational surface area.

What RisingWave Does

RisingWave embeds the Debezium engine for CDC capture and adds a SQL processing layer. Changes from the source database flow directly into RisingWave's materialized views. No Kafka required. No custom consumer code. The "target" is RisingWave itself — a PostgreSQL-compatible query interface.

RisingWave runs on AWS (self-hosted on EKS, or RisingWave Cloud) and stores data on S3. It is not a migration service; it is a stream processing database.

Head-to-Head Comparison

Cost Considerations

AWS DMS pricing is straightforward: you pay per replication instance hour and per GB of data migrated. A dms.t3.medium instance runs roughly $0.09/hour (~$65/month). For low-volume CDC, this is cheap. For high-volume or multi-table replication, you may need a larger instance class, and costs scale.

Hidden costs: DMS does not process data — it only moves it. You still need a target that can answer queries. If the target is Redshift, add Redshift costs. If it is Kinesis, add Kinesis costs plus consumer infrastructure.

Debezium has no software license cost, but running Kafka on MSK at production scale starts at $200–400/month for a three-broker cluster. Add Kafka Connect workers and monitoring, and the real cost is $500–1,000/month in managed infrastructure before your team's operational time.

RisingWave self-hosted on EKS fits into existing Kubernetes costs. RisingWave Cloud charges per resource unit. For teams already on EKS, the marginal cost of adding RisingWave is low.

Latency Characteristics

AWS DMS introduces latency through its replication instance, which polls the source's CDC mechanism (binlog for MySQL, logical replication for PostgreSQL). Latency is typically 1–10 seconds. For PostgreSQL on Aurora, DMS uses logical replication slots, and Aurora has a hard limit on concurrent replication slots.

Debezium latency depends on Kafka producer/consumer configuration. With default settings, latency is 1–3 seconds. With aggressive tuning (linger.ms=0, fetch.min.bytes=1), it approaches sub-second. But sub-second Kafka adds CPU overhead.

RisingWave reads directly from the database's replication protocol and updates materialized views in memory. Latency for query results is typically under one second.

A Realistic AWS Scenario

A team runs Aurora PostgreSQL as their operational database and wants real-time sales dashboards in Grafana.

With DMS:

Aurora PostgreSQL → DMS → Kinesis Data Stream → Lambda → DynamoDB → Grafana

Four AWS services to manage. Lambda functions to maintain. DynamoDB table design to optimize for Grafana query patterns. Total complexity: high.

With Debezium:

Aurora PostgreSQL → Debezium (on EC2/EKS) → MSK → Kafka Connect Sink → Redshift → Grafana

Managed Kafka, a Kafka Connect cluster, a Redshift cluster. Total: three managed services plus operational overhead.

With RisingWave:

-- Connect to Aurora
CREATE SOURCE aurora_cdc WITH (
  connector = 'postgres-cdc',
  hostname = 'my-cluster.cluster-xxx.us-east-1.rds.amazonaws.com',
  port = '5432',
  username = 'replication_user',
  password = 'secret',
  database.name = 'sales'
);

CREATE TABLE orders (
  id         BIGINT,
  product_id INT,
  quantity   INT,
  revenue    DECIMAL(10,2),
  region     VARCHAR,
  created_at TIMESTAMPTZ,
  PRIMARY KEY (id)
) FROM aurora_cdc TABLE 'public.orders';

CREATE MATERIALIZED VIEW hourly_sales AS
SELECT
  DATE_TRUNC('hour', created_at) AS hour,
  region,
  SUM(revenue) AS total_revenue,
  COUNT(*) AS order_count
FROM orders
GROUP BY 1, 2;

Grafana connects to RisingWave using the PostgreSQL driver and queries hourly_sales directly. One service, no pipeline glue.

When to Use Each

Use AWS DMS when:

• You need a one-time database migration to AWS with minimal CDC as a validation step.
• Your target is Redshift, DynamoDB, or another AWS service and you want zero infrastructure management.
• You do not need real-time processing, just replication.

Use Debezium when:

• Multiple independent consumers need the same change stream.
• You are building event-driven microservices with Kafka already in your stack.
• Your targets span cloud providers or on-premises systems.

Use RisingWave when:

• Your consumer is a SQL query engine or dashboard.
• You want to avoid operating Kafka.
• You need joins, aggregations, or windowed computations over CDC data.

FAQ

Can RisingWave and AWS DMS coexist? Yes, but it is redundant. If you use DMS to replicate to Redshift and also want real-time views, deploy RisingWave alongside DMS targeting the same Aurora source. Each reads from the replication slot independently.

Does DMS support transformation logic? DMS has basic column filtering and table mapping. It does not support SQL aggregations, joins, or windowing. For transformations, you need a separate compute layer.

What is the DMS replication slot limit on Aurora? Aurora PostgreSQL has a default limit of 10 concurrent replication slots. DMS consumes one slot per task. RisingWave also consumes one slot. Plan your slot budget if running both.

Is Debezium free to run on AWS? Debezium is open source with no license cost. Running it on AWS means paying for EC2 or EKS compute. Using MSK (managed Kafka) adds cost. Total cost depends on scale, not licensing.

Can RisingWave write results back to S3? Yes. RisingWave supports S3 as a sink target. You can configure a sink to export materialized view results to S3 in Parquet or JSON format for downstream use in Athena or other tools.