Shared performance · Burst Load + CDC

The number is only useful when the timer boundary is visible.

Burst Load source-to-target speed, CDC parser speed, durable capture speed, and target apply answer different questions. This page keeps the measurements separate, names the workload behind each one, and shows what must still happen after the timer stops.

10.5M rows/sec
Burst Load into BigQuery

Measured on a favorable source-to-target path. It is evidence for that workload, not a universal rate.

~390k rows/sec
SQL Server raw .ldf parser

Warm isolated parser probe. It does not include spool or target apply.

~173k records/sec
SQL Server Streaming baseline

Warm source-to-durable-spool baseline, including durable handoff.

112.5k events/sec
PostgreSQL pgoutput baseline

Source-to-durable-spool, including zstd compression and fsync.

300–375k rows/sec
Sybase warm decode range

Single-thread decoder baseline. Sink apply is outside this measurement.

Before you compare two numbers

Find the first component the benchmark did not measure.

01

Burst Load source → target

Times the complete table-movement path. Source read shape, row width, conversion, network, prepared files, and target ingestion all contribute.

02

Reader or decoder

Times byte scanning, parsing, or row decoding in isolation. Useful for finding CPU ceilings; incomplete as a pipeline promise.

03

Source → durable spool

Includes capture, event materialization, zstd compression, and durable spool writes with fsync. It still stops before a destination applies the change.

04

End-to-end apply

Starts at the source and stops only after the target has applied the change. Row shape, DML mix, target indexes, network, and apply strategy all matter.

Peak speed is not a capacity plan.

The measured Burst Load path into BigQuery reached 10.5M rows/sec, while a different pair will stop at a different source, network, conversion, or target boundary. CDC baselines also include MySQL binlog at roughly 21k records/sec from source to durable spool. Oracle DirectRedo ranges from roughly 4.9k records/sec on a mixed ERP OLTP workload to 407k on a favorable array-insert workload. The same reader spans about 80 times depending on transaction shape, which is why a peak without its workload can mislead.

Plan with your row widths, transaction sizes, insert/update/delete mix, network, and target indexes. Omni Loader’s durable spool absorbs differences in pace and preserves a checkpointed handoff. It cannot make a destination consume faster than that destination allows.

The benchmark that matters uses your rows.

Bring a representative schema, DML mix, source mode, and destination. We will agree on the timer boundary first, then measure capture and end-to-end apply without substituting an easier workload.