Zero-ETL Architecture: Is It Really Possible? (2026)
Kafka Connect with Debezium is the traditional CDC approach — capture changes with Debezium, transport via Kafka, process with a consumer. Native CDC in streaming databases (RisingWave, Flink CDC) eliminates the middleware, ingesting directly from the database transaction log.
Architecture Comparison
Kafka Connect + Debezium:
Database → Debezium (Kafka Connect) → Kafka → Consumer (Flink/App) → Serving DB
4-5 components. Requires Kafka cluster, Kafka Connect workers, and a downstream processor.
Native CDC (RisingWave):
Database → RisingWave → Query results / Iceberg sink
1 component. No Kafka, no Debezium.
Detailed Comparison
| Aspect | Kafka Connect + Debezium | RisingWave Native CDC |
| Components | 4-5 systems | 1 system |
| Latency | Seconds (multi-hop) | Sub-second |
| Source DBs | 10+ (PG, MySQL, MongoDB, SQL Server, Oracle) | PostgreSQL, MySQL |
| Processing | Separate consumer needed | Built-in SQL |
| Serving | Separate DB needed | Built-in PG protocol |
| Ops overhead | High | Low |
| Event bus | ✅ Kafka as central bus | ❌ Direct ingestion |
When to Choose
Kafka Connect + Debezium: Need CDC from MongoDB/SQL Server/Oracle. Want Kafka as a central event bus for multiple consumers. Already have Kafka infrastructure.
RisingWave Native CDC: Sources are PostgreSQL/MySQL. Want simplest possible pipeline. Need SQL processing + serving in one system.
Frequently Asked Questions
Is native CDC as reliable as Debezium?
Yes. Both read the database transaction log (WAL/binlog). RisingWave's native CDC provides the same change capture reliability with less operational complexity.
Can I use both approaches together?
Yes. Use Debezium for databases RisingWave doesn't support, stream through Kafka, and use RisingWave as the Kafka consumer for SQL processing.
