- Real-time data — changes land at the destination in seconds, not minutes
- Deletes captured — when a row is deleted at the source, it’s deleted at the destination
- Low source load — no polling queries; the agent reads the log that the database is already writing
How CDC works
Every major database maintains a log of changes (binlog, WAL, change tables). This log records every insert, update, and delete in order. Zwiron’s agent reads this log and applies the changes to the destination:Supported sources (live today)
Additional databases (MariaDB, SQL Server, Oracle, and others) are on demand — see More connectors on demand. Do not assume CDC is available for them until support enables the connector.
Setting up CDC on PostgreSQL
1. Enable logical replication
In yourpostgresql.conf:
2. Create a replication user
3. Create a publication
Zwiron will automatically create a replication slot and publication when CDC is first enabled. Or you can create it manually:4. Use CDC in Zwiron
When creating a pipeline, select CDC as the sync mode. Zwiron will handle the rest.Setting up CDC on MySQL
1. Enable binary logging
In yourmy.cnf:
2. Create a replication user
Requirements for CDC
- Primary key required — every table you want to CDC must have a primary key. Zwiron uses this to identify which row to update or delete at the destination.
- Replication must be enabled — see the database-specific instructions above.
- Log retention — the database must retain the change log long enough for Zwiron to read it. If CDC falls too far behind (e.g. agent offline for a long time), it may need to perform a full re-sync.
CDC vs. Incremental
Use Incremental if you just need efficiency. Use CDC if you need real-time data or need to capture deletes.