6 CDC source families

Start with the source you run. Choose the strongest CDC mode.

DirectLog, native CDC, logical replication, binlog, and reconstruction do not offer the same speed or record contract. Start with the fastest mode your hosting model can expose, then use the fallback when its tradeoff is the better fit.

CDC mode guide

Choose the fastest mode your source can expose

The database name is only the starting point. The right reader depends on file or device access, managed-service boundaries, privileges, logging settings, and the record contract your target needs. Each source below starts with the strongest available path, then explains why you would choose a slower alternative.

CDC source

Oracle

Catalog details →

Use the redo files when SQL Flow can reach them. Fall back to SQL mining when the hosting model keeps those files out of reach.

DirectLog

Start here

What it does

Reads binary redo on SQL Flow compute, draining archived redo and tailing online redo when the file layout is reachable.

Use it when

Redo paths, catalog access, and the required log-discovery permissions are available to the agent.

Why choose it

It moves parsing away from Oracle and avoids asking the database to run LogMiner. It is the first choice for high-throughput capture.

Tradeoff

ASM-only members or unreachable online redo rule it out. Unresolved LOB and object values remain explicit markers.

LogMiner

What it does

Mines V$LOGMNR_CONTENTS over SQL and emits typed changes plus schema events.

Use it when

The source permits SQL access but redo files cannot be exposed to the agent, or the deployment requires a database connection.

Why choose it

It works without direct redo-file access and can provide update/delete before-images when supplemental logging ALL is enabled.

Tradeoff

It is poll-based and consumes more Oracle CPU and SGA than DirectLog. Required privileges are often restricted on managed Oracle services.

If neither redo access nor the required LogMiner privileges are available, Oracle cannot provide this CDC contract.

CDC source

SQL Server

Catalog details →

Prefer raw log access for the fastest path. Use SQL Server’s CDC tables or log polling when file access is unavailable or the workload needs a different source contract.

DirectLog

Start here

What it does

Parses the raw .ldf continuously without enabling SQL Server CDC. Decode can run on separate compute, with a small read-only broker when needed.

Use it when

The agent or broker can reach the .ldf files and the tables do not depend on unsupported storage features.

Why choose it

It avoids CDC setup and moves the parsing work off the database host. This is the high-performance SQL Server path.

Tradeoff

Azure SQL, managed services without file access, and some memory-optimized, columnstore, or temporal workloads rule it out.

Built-in CDC

What it does

Reads SQL Server’s cdc.* change tables through the database connection.

Use it when

Raw log files cannot be exposed, or the workload includes tables better served by the native CDC contract.

Why choose it

It needs no file privilege and fits installations that already operate SQL Server’s CDC capture job.

Tradeoff

It is poll-based, inherits capture-job latency, and emits after-images only. Throughput is materially below DirectLog.

Polling with fn_dblog

What it does

Reads the active log through sys.fn_dblog and reconstructs after-image records from log and row state.

Use it when

File access is unavailable, CDC is not enabled, and controlled sysadmin access is acceptable.

Why choose it

It avoids a CDC setup and can work where a connection is available but the log files are not.

Tradeoff

It is slower and poll-based, requires sysadmin, and carries source-specific recovery and cold-start limits.

For Azure SQL, use the separate Azure SQL native CDC path below; the service does not expose SQL Server DirectLog or fn_dblog.

CDC source

Azure SQL

Catalog details →

Azure SQL is managed, so the source exposes a narrower CDC contract than a self-hosted SQL Server.

Native CDC

Start here

What it does

Reads Azure SQL CDC tables through the dedicated managed-service connector.

Use it when

CDC is enabled and the service tier exposes the required CDC objects.

Why choose it

It is the fastest and safest path Azure SQL makes available without depending on host-level log access.

Tradeoff

It remains poll-based and inherits Azure SQL’s CDC capture and polling latency. Raw log access and fn_dblog are not available.

There is no DirectLog fallback for Azure SQL. If the service cannot expose CDC, SQL Flow cannot claim a continuous log-capture path.

CDC source

PostgreSQL

Catalog details →

PostgreSQL’s native logical replication path is the production choice. It preserves transaction-aware changes without a slower SQL polling substitute.

Logical replication: pgoutput

Start here

What it does

Consumes a native logical-replication slot for inserts, updates, deletes, TRUNCATE, and relation-diff schema events.

Use it when

wal_level is logical, the login has REPLICATION, and the hosting model permits logical slots.

Why choose it

It is push-based and commit-latency bound, with native transaction ordering and explicit unchanged-TOAST behavior.

Tradeoff

Complete before-images require suitable replica identity, and managed services may restrict slots or replication privileges.

SQL Flow does not replace pgoutput with a slower polling reader. If logical replication is unavailable, the source must be changed or its CDC scope reduced.

CDC source

MySQL

Catalog details →

Use the row binlog as the source of truth. MySQL has no lower-performance SQL reader that provides the same transaction and row-image contract.

Binlog: row replication

Start here

What it does

Streams row events with before-images, after-images, commit-grouped transactions, schema changes, and full TEXT and BLOB values.

Use it when

binlog_format is ROW, binlog_row_image is FULL, and the service permits a replication client.

Why choose it

It is push-based with no polling interval and keeps the source-to-target contract tied to committed row events.

Tradeoff

The binlog settings and replication privileges must be correct. The current checkpoint contract is file plus offset rather than GTID failover.

If row-binlog access is unavailable, SQL Flow does not substitute a slower SQL polling path and cannot promise equivalent CDC behavior.

CDC source

SAP ASE

Catalog details →

Use the raw log device when it can be reached. Use reconstruction over TDS when device access is impossible but a slower, connection-based path is acceptable.

DirectLog

Start here

What it does

Walks new 16 KB pages on the raw ASE log device and uses TDS only for metadata.

Use it when

The device is reachable through file, Docker, SSH, or a privileged broker and the physical layout is supported.

Why choose it

It delivers the high-performance path while preserving typed values, before-images, and after-images on supported layouts.

Tradeoff

It needs device access and supported ASE/storage layouts. Device reachability and moved-row behavior must be tested on the actual workload.

Reconstruction: dbcc log / page

What it does

Uses TDS to identify changes with dbcc log and reconstruct typed row images with dbcc page.

Use it when

The raw log device cannot be exposed, but TDS access and sufficient log retention are available.

Why choose it

It avoids privileged device access and works across a wider deployment boundary.

Tradeoff

It scans the held log, is poll-based, and is not the high-throughput device path. Storage layout and retention limits remain important.

If the device is unavailable and log retention cannot support reconstruction, SAP ASE needs a deployment or retention change before CDC can be made reliable.

Choose the exact reader, not only the database logo.

Tell us engine version, hosting model, recovery settings, privileges, and workload. We will identify the fitting capture mode and the prerequisites to test.

Check my source Compare capture modes

SQL Flow handles automatically

The software does the migration work.

  • SQL Flow discovers source metadata and applies the supported reading method.
  • Tables, keys, types, and required CDC prerequisites are identified automatically.
  • Full-load and change records enter the same operating model.

You choose

Keep control of the decisions that matter.

  • Choose the source database and data scope.
  • Select the supported capture mode.
  • Set source resource limits and security policy.