Write to MySQL. Read it in PostgreSQL.
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.
Log-based capture: MySQL binlog or PostgreSQL logical replication, self-hosted or managed.
MySQL 
MariaDB 
Percona 
PostgreSQL 
Amazon RDS 
AWS Aurora 
Google Cloud SQL 
Azure Database 
Neon 
Supabase 
YugabyteDB 
DigitalOcean Any PostgreSQL or MySQL-compatible database, plus Snowflake. Files and S3 take a full load only.
MySQL PostgreSQL Amazon RDS AWS Aurora Google Cloud SQL Azure Database Neon Supabase 
Databricks Lakebase YugabyteDB 
Snowflake DigitalOcean Databricks Lakebase is a target only: it blocks the publication that logical decoding needs, so it cannot be a CDC source. YugabyteDB reads and writes changes, but as a source it needs two settings on its own cluster first — a PostgreSQL-compatible replica identity and the before-image flag — both in the YugabyteDB guide. Snowflake is a target only too, and takes changes through Snowpipe Streaming rather than row-by-row writes: they land in a change table that a Snowflake task merges into the ordinary table you query. There is no CDC for Oracle or SQL Server, though the DBConvert desktop tools do migrate them.
Measured Performance
Real numbers from local replication tests with 10,000-row transactions.
64,000/s
rows applied from bulk transactions
0.2 s
behind the source at 40,000 changes/s, bulk transactions
1 ms
for a single-row change
0 lost
at 75,000 changes/s overload
Example: MySQL → PostgreSQL — 64,000 rows per second applied from bulk transactions, 0.2 s behind MySQL at 40,000 changes per second
A full load first, then changes from the transaction log. Default database settings, nothing tuned.
Time from the commit in MySQL until the row is visible in PostgreSQL. MySQL 8 → PostgreSQL 16 on one desktop machine, default settings; every change set is a 10,000-row transaction, held at each rate for 60 seconds.
| Changes per second | Half of rows arrive within | 95% within | All within |
|---|---|---|---|
| 21,000 | 0.13 s | 0.19 s | 0.24 s |
| 40,000 | 0.14 s | 0.20 s | 0.35 s |
| 60,000 | 0.24 s | 1.01 s | 1.12 s |
| 75,000 | 8.8 s | 17.5 s | 18.2 s |
At 75,000 changes per second the source outpaces the target: changes queue up and lag grows for as long as the overload lasts. Once it ends the queue drains, and all 4.5 million rows arrive — none lost.
The same throughput with PostgreSQL as the source: about 65,000 rows per second applied, and half of the rows within 0.4 s at every rate up to 60,000 changes per second.
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.
Open a run for live metrics and checkpoint position; the config rail keeps that config’s run history together in the UI and 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.
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 selected config makes the CDC scope, source and target, schema policy, and write mode explicit before you start. Each start then appears as a separate run under that config.
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 MySQL or PostgreSQL changes into Snowflake tables, merged by primary key on the schedule you choose.
Debezium — log-based CDC with Kafka.
Airbyte — log-based CDC, orchestrated as recurring sync jobs.
DBConvert Streams — continuous CDC without external infrastructure.
Weighing more of them? Database replication software — 11 tools compared.
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.
Use built-in AI Chat over the read-only DBConvert toolset to inspect stream status, recent errors, and logs, then decide the fix.
Further reading
Binlog CDC methods compared — trigger, query, and log-based — with configuration steps and production pitfalls.
Replication slots, output plugins, and a working WAL consumer — how Postgres logical decoding actually works.
The conceptual guide: what CDC is, when to use it, and how the capture methods trade off.
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.
In production, CDC is priced per pipeline: one CDC stream running at a time.
See Product Overview