Supermetal
A Rust-based CDC platform that moves data from a database WAL to a committed Iceberg table on S3 in one process — WAL → Arrow → Parquet, columnar end-to-end, no Kafka or JVM in the path.
Summary
A Rust-based CDC platform that moves data from a database WAL to a committed Iceberg table on S3 in one process — WAL → Arrow → Parquet, columnar end-to-end, no Kafka or JVM in the path.
The strongest single-node challenger to the Debezium→Kafka→Flink pipeline: 13-minute Postgres→Iceberg snapshot (TPC-H SF50) vs Flink CDC's 90–116 minutes, untuned. The phase-aware Iceberg writer (append-only during snapshot, V3 deletion vectors live) is its signature trick.
- Single-process means vertical scaling — it does not replace Flink CDC for distributed exactly-once workloads at extreme throughput.
- Benchmark numbers are single-node normalized; multi-node Flink deployments change the comparison.
alternative_toFlink CDC / Debezium — same CDC job, one process instead of a pipelineenablesApache Iceberg — first-class Iceberg V2/V3 targetsolvesLegacy Ingestion Bottlenecks — collapses the multi-hop serialization tax
Definition
A Rust-based CDC/data-integration platform that moves data from a database's write-ahead log to a committed Apache Iceberg table on S3 in a **single process** — no Kafka, no ZooKeeper, no intermediate JVM stream processor. WAL events decode directly into Apache Arrow record batches and write out as Parquet: columnar end-to-end, eliminating the serialize-to-JSON/deserialize-in-Flink/re-serialize-to-Parquet tax of the traditional Debezium→Kafka→Flink pipeline. Per [Supermetal — Announcing the Apache Iceberg target](https://supermetal.io/blog/iceberg-target).
For a large class of workloads, the multi-hop CDC architecture exists for historical reasons, not technical ones. Supermetal's bet is that a phase-aware single process beats a distributed pipeline on everything but extreme scale: during snapshot it runs a highly parallelized append-only mode (no dedup, perfectly sized Parquet straight to S3); when it transitions to live CDC it switches to writing **Iceberg V3 deletion vectors** (or V2 position deletes) for update handling — the writer changes behavior by pipeline phase, a sideways-information-passing trick borrowed from database engines.
Postgres/MySQL→Iceberg replication without operating Kafka or Flink, fast initial snapshots of large operational databases into the lakehouse, small-team CDC where the pipeline must be one deployable unit, migrations off multi-hop Debezium stacks.
Recent developments
- The benchmark that reframed the category (April 2026). The New Stack's normalized single-node comparison (TPC-H SF50, ~375M rows, 3 CPU / 13 GB on EKS): Supermetal snapshots Postgres→Iceberg in 13 minutes vs Flink CDC's 90–116, Kafka Connect/Debezium's 120, and Spark's 200+ — at <5% of allocated RAM, with zero tuning. An earlier February benchmark measured 275 MB/s peak untuned vs Flink CDC's 84 MB/s at parallelism 16. Per Postgres to Iceberg in 13 minutes (The New Stack) and Benchmarking CDC Tools (StreamingData.tech).
Connections 7
Outbound 7
scoped_to2enables2solves1Resources 3
Primary engineering description of the WAL→Arrow→Parquet single-process architecture and the phase-aware Iceberg writer (append-only snapshot mode, V3 deletion vectors live).
The independent normalized benchmark (TPC-H SF50, single node) behind the 13-min-vs-90-min claim against Flink CDC, Kafka Connect, and Spark.
Earlier February 2026 throughput benchmark (275 MB/s untuned vs Flink CDC 84 MB/s at parallelism 16) — corroborates the New Stack numbers from a second methodology.