Start with the access you have. Choose the fastest honest path.
DirectRedo, raw-.ldf Streaming, and DirectDevice move high-performance parsing onto Omni Loader compute when logs are reachable. Native streams and SQL readers cover environments that expose less host access. Compare all ten paths by source cost, record contract, measurement boundary, and the condition that rules each one out.
Access narrows the list. Workload chooses the winner.
First rule out the paths your hosting model and privileges cannot expose. Then compare the source work, record behavior, and measured boundary against the workload you actually run.
Oracle
DirectRedo: binary redo parser
High-performance direct logReads binary redo without asking Oracle to run LogMiner. It drains archived redo from the durable checkpoint, then tails online redo when the file layout is reachable. If online redo is not reachable, it continues on the archive cycle. It emits committed inserts, updates, and deletes with typed scalar values. Unresolved LOB and object values remain explicit bare-string markers.
Parsing runs on Omni Loader compute instead of inside Oracle. Source-to-durable-spool results vary sharply with redo shape. Current lab runs range from 4.9k rows/sec on an ERP OLTP workload to 407k rows/sec on a favorable array-insert workload.
The agent cannot read the redo paths, including ASM-only members; the required catalog and log-discovery access is unavailable; or online redo file layout is unreachable and archive-cycle latency is unacceptable.
LogMiner
Mines V$LOGMNR_CONTENTS over SQL. It emits typed values, update and delete before-images when supplemental logging ALL is enabled, and unified schema-change events from DDL rows and catalog checks.
This path is poll-based and bounded by Oracle’s mining work. Expect materially more source CPU and SGA pressure than DirectRedo. Internal characterization places it in the thousands of rows per second rather than raw-parser territory.
The required LogMiner, ARCHIVELOG, supplemental-logging, or CDB-root privileges are unavailable. Omni Loader does not claim this path for Autonomous or RDS where those privileges are commonly restricted.
SQL Server
Streaming: raw .ldf
High-performance direct logParses the raw .ldf continuously without SQL Server CDC setup. It decodes ROW and PAGE compression plus SCSU strings, emits after-image records, and uses typed references when off-row, page-dictionary, or encrypted values cannot be resolved. A tiny privileged broker can provide allowlisted read-only bytes while decode runs on separate compute.
~390k rows/sec is the isolated raw-parser result. The current lab source-to-durable-spool baseline is ~173k rows/sec. Those are different boundaries and neither is an end-to-end apply promise.
The agent or broker cannot reach the .ldf; the source is Azure SQL, MI, RDS, or another service without file access; or tables use memory-optimized, columnstore, or temporal storage.
Built-in CDC: SQL Server
Reads SQL Server’s cdc.* change tables. Choose it when log-file access is unavailable or the workload includes memory-optimized tables. Like every SQL Server reader in Omni Loader, it emits after-image records rather than before-images.
Indicative ~20k rows/sec. It is poll-based and inherits the SQL Agent capture job’s latency floor, but avoids raw-file privileges.
The edition lacks CDC (Express/Web), or you need TRUNCATE captured (SQL Server doesn’t surface it on CDC tables).
Native CDC: Azure SQL
Uses Azure SQL CDC tables through the dedicated Azure SQL source connector. Omni Loader rejects polling and raw-log Streaming for Azure SQL because the service does not expose those paths.
Managed-service friendly and poll-based. Throughput and latency inherit Azure SQL CDC capture and polling behavior.
CDC cannot be enabled on the database, the service tier does not expose the required CDC objects, or you need raw-log access that Azure SQL does not provide.
Polling: fn_dblog
Reads the active log through sys.fn_dblog without CDC setup, then reconstructs after-image records from log and row state. The SQL Server typed-reference contract keeps unresolved storage values explicit.
Indicative ~10k rows/sec; poll-based with moderate source work. Use it when file access is unavailable but sysadmin access is acceptable.
You lack sysadmin; the source is managed cloud; recovery is SIMPLE; or the known cold-start moved-row edge is unacceptable for your workload.
PostgreSQL
Logical replication: pgoutput
Uses a native logical-replication slot for inserts, updates, deletes, and first-class TRUNCATE. It emits an explicit unchanged-TOAST sentinel and relation-diff schema events. Before-images follow each table’s replica identity.
Push-based and commit-latency bound. The current source-to-durable-spool lab baseline is 112.5k events/sec, including spool compression and fsync.
wal_level is not logical; the login lacks REPLICATION; the managed service blocks logical slots; or you need complete before-images without REPLICA IDENTITY FULL.
MySQL
Binlog: row replication
Streams row events from the binary log with before-images, after-images, commit-grouped transactions, schema-change events, full TEXT and BLOB values, and decoded zstd-compressed transaction payloads.
Push-based with no polling interval. The current source-to-durable-spool lab baseline is 21k events/sec; network, row width, transaction shape, and binlog configuration determine your result.
binlog_format is not ROW; binlog_row_image is not FULL; the service does not allow a replication client; or you require GTID-based failover. The current checkpoint is file plus offset.
Sybase ASE
DirectDevice: raw log device
High-performance direct logWalks new 16 KB pages on the raw ASE log device and uses TDS only for metadata. It emits typed values plus before-images and after-images for APL and data-only-locked layouts. File, Docker, SSH, and privileged-broker device access are wired into the source.
The current plan records ~300–375k rows/sec for warm single-thread decode. That is a decoder measurement, not an end-to-end destination rate.
The device is unreachable; ASE is not 16.0; a table uses compressed storage; the physical layout cannot be identified; or you require exact per-record recovery under moved-row churn.
Reconstruction: dbcc log / page
Uses TDS only. dbcc log text identifies changes, and dbcc page reconstructs typed row images. It emits before-images and after-images without direct device access.
Poll-based and optimized with object-id and operation filters. It avoids a file-access requirement, but still scans the held log and is not the high-throughput device path.
Log retention is unmanaged during a long run, or a table uses data-only locking or compressed storage. Its asserted guarantee is no loss. It does not claim exact per-record after-image recovery under every page-compaction case.
Numbers on this page come from different test boundaries by design. “Isolated parser,” “source to durable spool,” and “end to end” are not interchangeable. Treat them as evidence about architecture. Your schema, row width, storage, and target still determine the result.
Rule out the wrong capture paths first.
Tell us the source, deployment model, table shapes, and permissions you can grant. We will narrow the field, explain the source cost, and benchmark the strongest candidate on a representative workload.