Schema evolution and DDL propagation

Keep structure moving with the data without making DDL invisible.

SQL Flow emits versioned schema events with row changes, updates decode plans, and applies compatible target changes automatically.

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.

Readers emit normalized schema events, spool frames preserve them, and sinks consume them before dependent batches. Caches invalidate at the same boundary. SQL Flow handles add, alter, rename, truncate, and drop event model; schema version attached to row batches; ordered replay after restart or relay; per-engine identifier and type mapping.

Why this path matters

Detect, persist, replay, and apply one versioned contract.

Readers emit normalized schema events, spool frames preserve them, and sinks consume them before dependent batches. Caches invalidate at the same boundary. SQL Flow handles add, alter, rename, truncate, and drop event model; schema version attached to row batches; ordered replay after restart or relay; per-engine identifier and type mapping.

What changes for you

Operators choose whether compatible changes apply automatically, require approval, or stop. Destructive changes show source DDL, target impact, and recovery action. SQL Flow handles automatic compatible target DDL; approval for policy-controlled changes; schema event history and audit; coordinated multi-master evolution.

The outcome

Bring representative DDL, mapping rules, and target constraints. We will map automation and approval.

The payoff

See what the capability changes.

Ordered

DDL + DML

Schema versions travel with dependent changes.

Automatic

Compatible evolution

Additive and mapped changes propagate.

Fail safe

Destructive changes

Risky DDL stops at an approval boundary.

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.

End-to-end events

Detect, persist, replay, and apply one versioned contract.

Readers emit normalized schema events, spool frames preserve them, and sinks consume them before dependent batches. Caches invalidate at the same boundary.

SQL Flow handles add, alter, rename, truncate, and drop event model; schema version attached to row batches; ordered replay after restart or relay; per-engine identifier and type mapping.

  • Add, alter, rename, truncate, and drop event model
  • Schema version attached to row batches
  • Ordered replay after restart or relay
  • Per-engine identifier and type mapping

Policy before mutation

Automate safe changes and surface the rest.

Operators choose whether compatible changes apply automatically, require approval, or stop. Destructive changes show source DDL, target impact, and recovery action.

SQL Flow handles automatic compatible target DDL; approval for policy-controlled changes; schema event history and audit; coordinated multi-master evolution.

  • Automatic compatible target DDL
  • Approval for policy-controlled changes
  • Schema event history and audit
  • Coordinated multi-master evolution

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.

  • Add, alter, rename, truncate, and drop event model
  • Schema version attached to row batches
  • Ordered replay after restart or relay
  • Per-engine identifier and type mapping
  • Automatic compatible target DDL
  • Approval for policy-controlled changes

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. Detect, persist, replay, and apply one versioned contract.

    Readers emit normalized schema events, spool frames preserve them, and sinks consume them before dependent batches. Caches invalidate at the same boundary. SQL Flow handles add, alter, rename, truncate, and drop event model; schema version attached to row batches; ordered replay after restart or relay; per-engine identifier and type mapping.

  2. Automate safe changes and surface the rest.

    Operators choose whether compatible changes apply automatically, require approval, or stop. Destructive changes show source DDL, target impact, and recovery action. SQL Flow handles automatic compatible target DDL; approval for policy-controlled changes; schema event history and audit; coordinated multi-master evolution.

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

  • DDL + DML
  • Compatible evolution
  • Detect, persist, replay, and apply one versioned contract.
  • Automate safe changes and surface the rest.
  • Make schema change part of the replication contract.

Take the next step

Make schema change part of the replication contract.

Bring representative DDL, mapping rules, and target constraints. We will map automation and approval.

Talk through my use case