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.

Parallel table movement
Move large datasets without a serial bottleneck

Split tables and independent ranges across workers so migrations can use the source, network, and target capacity available to them.

Durable change capture
Keep committed changes moving safely

Read the database’s native log and preserve a durable handoff before delivery, so downstream work can catch up without losing the stream.

Zero-downtime migration handoff
Seed, catch up, validate, and cut over

Combine the initial load and live changes while the source stays available, then switch over from a known, validated position.

Target-aware delivery
Apply changes where your systems actually run

Coordinate delivery with row shape, indexes, network limits, and target behavior instead of optimizing an isolated reader number.

Recoverable operations
Resume from a checkpoint when work is interrupted

Retain completed slices and retry unfinished work instead of restarting an entire load.

Before you compare two numbers

Find the first component the benchmark did not measure.

Burst Load source → target

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

Reader or decoder

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

Source → durable spool

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

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.

Production performance is a system property.

SQL Flow improves useful throughput by combining parallel table movement, native log capture, durable handoff, and target-aware delivery. The result is a migration and replication path that keeps working when source and destination workloads do not move at the same pace.

The right design still depends on row widths, transaction sizes, insert/update/delete mix, network, and target indexes. SQL Flow absorbs differences in pace and preserves a checkpointed handoff; it does not pretend a fast source can make a constrained destination consume faster than it 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.

SQL Flow handles automatically

The software does the migration work.

  • SQL Flow measures full load, capture, durable transfer, and target apply separately.
  • Parallel work is balanced automatically across useful capacity.
  • The limiting stage remains visible instead of being hidden in one aggregate rate.

You choose

Keep control of the decisions that matter.

  • Choose maximum throughput or bounded production impact.
  • Set worker, bandwidth, memory, and batching limits.
  • Choose which stage or table to optimize first.