Technology

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.

7 connections 3 resources 1 post

Summary

What it is

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.

Where it fits

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.

Misconceptions / Traps
  • 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.
Key Connections
  • alternative_to Flink CDC / Debezium — same CDC job, one process instead of a pipeline
  • enables Apache Iceberg — first-class Iceberg V2/V3 target
  • solves Legacy Ingestion Bottlenecks — collapses the multi-hop serialization tax

Definition

What it is

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).

Why it exists

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.

Primary use cases

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

Latest signals
  • 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

Resources 3

Featured in