Shared platform · Deployment

Unpack the runtime. Place the workers where the data is.

SQL Flow ships as native Windows and Linux archives. Run one process for a standalone migration or coordinate agents across machines for more capacity and network locality.

The job to be done

Move committed data with a path your team can explain.

A capability matters when it removes an operational decision, not when it adds another checkbox. SQL Flow connects source-aware capture, durable progress, target apply, and validation so the page you are reading leads to a usable operating path.

Run SqlFlow.exe on Windows or SqlFlow on Linux and bind the web server to the selected port. A standalone process is enough for local evaluation and migrations that fit one machine.

Why this path matters

Start the executable and open the built-in interface.

Run SqlFlow.exe on Windows or SqlFlow on Linux and bind the web server to the selected port. A standalone process is enough for local evaluation and migrations that fit one machine.

What changes for you

Start SQL Flow with --cluster, then point Windows or Linux agents at the orchestrator address. Place agents on separate machines when additional compute, source locality, or target locality improves the real path. SQL Flow handles one orchestrator; agents on separate machines; explicit listen and advertised endpoints; burst Load and CDC on shared deployment foundations.

The outcome

Tell us the source and target networks, operating systems, and available machines. We will map standalone or clustered placement for Burst Load and CDC.

The payoff

See what the capability changes.

Windows + Linux

Native distributions

Use the operating system already approved for the migration environment.

Standalone

One-machine start

Launch the built-in web interface and worker from one runtime.

Cluster

Distributed agents

Add machines where more workers or network locality help.

Where the work happens

The details that make the result usable.

Read each capability as part of the operating path. The important question is not whether a feature exists, but what work it removes and what evidence it leaves behind.

Standalone mode

Start the executable and open the built-in interface.

Run SqlFlow.exe on Windows or SqlFlow on Linux and bind the web server to the selected port. A standalone process is enough for local evaluation and migrations that fit one machine.

Cluster mode

Separate orchestration from distributed work.

Start SQL Flow with --cluster, then point Windows or Linux agents at the orchestrator address. Place agents on separate machines when additional compute, source locality, or target locality improves the real path.

SQL Flow handles one orchestrator; agents on separate machines; explicit listen and advertised endpoints; burst Load and CDC on shared deployment foundations.

  • One orchestrator
  • Agents on separate machines
  • Explicit listen and advertised endpoints
  • Burst Load and CDC on shared deployment foundations

Console mode

Run the same deployment headlessly.

Pass a JSON job with --job for scheduled and CI/CD migrations. Structured logs record the automated run while secrets and network placement stay inside the environment you control.

Before you choose

Check the path against your environment.

Use the page-specific details below as a short discovery checklist. They are the conditions and work areas that shape the capability, not generic product promises.

  • One orchestrator
  • Agents on separate machines
  • Explicit listen and advertised endpoints
  • Burst Load and CDC on shared deployment foundations

The path to confidence

See the work. Make the call. Prove the result.

The page keeps the product detail close to the decision it supports. Your team can see what the software handles automatically, what it changes for the target, and what the result leaves ready to operate.

  1. Start the executable and open the built-in interface.

    Run SqlFlow.exe on Windows or SqlFlow on Linux and bind the web server to the selected port. A standalone process is enough for local evaluation and migrations that fit one machine.

  2. Separate orchestration from distributed work.

    Start SQL Flow with --cluster, then point Windows or Linux agents at the orchestrator address. Place agents on separate machines when additional compute, source locality, or target locality improves the real path. SQL Flow handles one orchestrator; agents on separate machines; explicit listen and advertised endpoints; burst Load and CDC on shared deployment foundations.

  3. Run the same deployment headlessly.

    Pass a JSON job with --job for scheduled and CI/CD migrations. Structured logs record the automated run while secrets and network placement stay inside the environment you control.

Keep the plan connected

Take the next useful step.

A capability becomes easier to operate when the next decision follows from the constraint you just uncovered. Explore the related work that completes this part of the path.

Your working set

What this page leaves you with

  • Native distributions
  • One-machine start
  • Start the executable and open the built-in interface.
  • Separate orchestration from distributed work.
  • Put the workers close to the work.

Take the next step

Put the workers close to the work.

Tell us the source and target networks, operating systems, and available machines. We will map standalone or clustered placement for Burst Load and CDC.

Talk through my use case