Change data capture (CDC) keeps a target system updated by reading changes from the source database's transaction log — MySQL's binlog or PostgreSQL's WAL — instead of polling for differences. Reading the log is the easy part; the hard parts are starting safely after the initial load, checkpointing only after the target acknowledges the write, and preserving order when changes are applied to the target in parallel.
DBConvert Streams reads the binlog or WAL directly, normalizes events into a single internal format, and writes them to the target through embedded JetStream — no external Kafka, no separate orchestrator. Checkpoints advance only after the target write is acknowledged, per-table ordering is preserved, and the same workflow can either start from live changes only or bootstrap an empty target first and continue with CDC.
Measured Performance
Real numbers from local replication tests.
100 MB/s
local transfer rate
50+ GB
verified, no upper limit
~10M rows
replicated in seconds
Per-stream
parallel processing
<10 ms
processing latency
Example: MySQL → PostgreSQL — 1,000,000 rows in ~4 seconds (~100 MB/s)
Per-stream routing and worker pools for stable throughput, with protocol-native CDC readers and optimized bulk-write paths.
From transaction logs to reliable delivery in four steps.
Connects directly to MySQL binlog or PostgreSQL logical replication slots. Committed row changes are decoded from the source log and streamed as CDC events.
Changes are normalized into a unified internal event format. Rolled back transactions are not delivered to the target.
Events are written to target destinations. CDC messages are acknowledged only after the target write succeeds.
Live metrics, checkpoint position, per-table progress, and full stream history are visible in the UI and via API.
Built for continuous CDC on stable infrastructure, with JetStream-backed buffering, commit-aware checkpoints, and explicit failure state when the target cannot accept a write.
Stream changes to operational databases, analytics stores, and storage layers without additional infrastructure.
Some teams start from live changes only. Others need the same CDC run to bootstrap an empty target first and then keep it current.
CDC only
Use this when the target is already prepared and the main goal is ongoing replication from the current log position forward.
Initial Load + CDC
Use this when one CDC run should copy existing rows into an empty target first and then continue with live changes for controlled cutover.
The Replication Status stepper shows snapshot completion, handoff, and CDC apply while the stream is writing into PostgreSQL.
Stream production MySQL into a PostgreSQL analytics replica without impacting primary workload.
Run a snapshot migration first, then keep changes flowing with CDC while you plan cutover.
Maintain a continuously synchronized standby database across regions or providers.
Stream database changes into compressed Parquet or CSV files with Hive-style partitioning.
Related workflows
Load the target before changes flow, validate what the stream applies, query the result, or hand diagnostics to your AI.
Run the initial snapshot migration to populate an empty target, then continue with CDC from the consistent point.
Inspect rows, compare source and target, and confirm the stream is applying changes as expected.
Join the replicated target with other databases, files, or S3 in one query once changes are flowing.
Stream stopped overnight? Over MCP your assistant checks status, recent errors, and logs, then points at the fix — you run it.
On MySQL it reads the binary log (binlog) using the standard replication protocol — the same one a MySQL replica uses. On PostgreSQL it reads from a logical replication slot using the standard logical-decoding output. No triggers, no polling, no source-side schema changes.
No. Delivery is at-least-once, which means a target write may occasionally repeat after a failure. Targets should be configured with idempotent writes (upsert / merge by primary key) so that retries do not produce duplicates.
The CDC checkpoint is not advanced until the target acknowledges the write. If the target rejects a write or becomes unavailable, the stream stops in an explicit failure state and resumes from the last committed checkpoint when restarted — not from the latest source position.
CDC events are emitted only after the source commits a transaction. Long-running transactions delay the visibility of their events because the entire transaction is held until commit. This is a property of log-based CDC in general, not specific to DBConvert Streams.
DBConvert Streams does not automatically replicate DDL. When you change the source schema (for example, add a column or change a type), apply the corresponding compatible change to the target as part of your operational procedure, then resume the stream.
Validate source and target state first, then run the CDC path you plan to use for cutover.
Use pricing when you are ready to size production streams and team seats.
See Product Overview