rustcdc

Documentation

Capture row-level changes from PostgreSQL, MySQL, MariaDB, SQL Server or Snowflake — as a server you run or a Rust crate you embed.

rustcdc reads a database's replication log and turns every INSERT, UPDATE and DELETE into a typed event. You can run it as a server or embed it as a Rust library — same runtime, same version, one set of guarantees.

These pages cover both. Where something applies to only one, the page says so at the top.

A change flows from the database log through capture, transforms and the commit barrier to a sink, with the checkpoint advancing only after the sink accepts it Database WAL · binlog · CDC tables Capture snapshot + stream Transforms mask · route · WASM Commit barrier ordering Sink Kafka · Iceberg · … acknowledged → checkpoint advances
The durable position never advances past an event the sink has not accepted.

Start here
Getting startedRun the server against a database in about ten minutes
Embedding the libraryBuild a pipeline inside your own Rust binary
Core conceptsThe event model, delivery contracts, lifecycle
ArchitectureCapture, the commit barrier and checkpointing — how they fit

Connect a source
PostgreSQLLogical replication, slot lifecycle, TOAST, managed clouds
MySQL / MariaDBBinlog, GTID, schema history, permissions
SQL ServerCDC change tables, capture instances, availability groups
SnowflakeThe CHANGES clause, and why Streams are unsafe for an external reader

Configure
Server configurationEvery TOML field, with defaults and worked examples
Library optionsEvery RuntimeOptions field, in terms of the failure it prevents
Schema evolutionDDL handling, schema history, registry compatibility
Feature flagsWhat each cargo feature costs and why connectors are opt-in

Build on it
API guideThe embedding model: lifecycle, acknowledgement, transforms, codecs
TransformsMasking, routing, outbox, and sandboxed WASM modules
WASM transform SDKThe guest ABI and its limits
Writing a connectorA source the runtime treats as first-class

Run it
DeploymentKubernetes, health wiring, resource shape
OperationsCLI, probes, metrics, replay
Incident runbookSymptom → diagnosis → resolution, for the server
Embedded pipelinesAlert thresholds and recovery when you own the process
TroubleshootingOrganised by symptom
SecurityTransport defaults, secret handling, known exposure

Reading the delivery guarantees

Two claims are load-bearing, and both are narrower than the words usually imply:

  • at_least_once — a crash can replay the events of one uncheckpointed batch. Duplicates are possible; loss is not. Sinks must be idempotent on a key you control.
  • effectively_once — a batch's records and its checkpoint commit together: in one Kafka transaction, or by a Snowflake channel's offset token. It is not end-to-end exactly-once in every configuration, and the limits are written down rather than glossed over.

Where a guarantee has a limit, the limit is next to the guarantee. If rustcdc cannot do something, these pages say so.