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 
DigitalOcean Any PostgreSQL or MySQL-compatible database, plus object storage and files.
MySQL PostgreSQL Amazon RDS AWS Aurora Google Cloud SQL Azure Database Neon Supabase 
Databricks Lakebase DigitalOcean 
S3 / MinIO 
Local files 
Snowflake Coming soonDatabricks Lakebase is a target only: it blocks the publication that logical decoding needs, so it cannot be a CDC source. 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.
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.
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 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.
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.
Use pricing when you are ready to size production streams and team seats.
See Product Overview