Missing tables get created
When the destination table isn’t there, the flow generates the CREATE TABLE from the source fields and runs it. On by default for new transformations.
Schema drift
Your source changed. Nothing broke.
Tables get created, columns get added, keys and indexes come along, and objects are picked by wildcard instead of by name. Every pipeline type reads the destination as it actually is before it writes.
What happens when a column appears
- idINTEGER
- first_nameTEXT
- last_nameTEXT
- emailTEXT
- idINTEGER
- first_nameTEXT
- last_nameTEXT
- emailTEXT
- idINTEGER
- first_nameTEXT
- last_nameTEXT
- emailTEXT
- phoneTEXTnew
- idINTEGER
- first_nameTEXT
- last_nameTEXT
- emailTEXT
- phoneTEXTnew
No mapping edit, no redeploy, no failed run. The same applies when the table itself is missing — it gets created, with the source’s keys and indexes.
Capabilities
What’s built in.
Keys and indexes come along
Turn on Create Indexes and a database source’s indexes are replicated on the destination as the table is created, not bolted on afterwards.
New columns arrive by ALTER TABLE
A source column the destination doesn’t have becomes an ALTER TABLE ADD, one per column. Off by default, so schema changes never surprise you.
Objects picked by wildcard
Point a flow at public.* instead of naming tables. New tables that match are picked up on the next run, with include and exclude lists and parallel execution.
Every pipeline reads the real schema
ETL, ELT, bulk load, and CDC all inspect the destination before writing and adapt to what is actually there, rather than selecting a column list someone wrote once.
Your rules, at the connection
Data Type Overrides remap source types to the types you want, for every flow on that connection. When that is not enough, override the generated CREATE and ALTER SQL with JavaScript.
Mapping that starts already done
Source fields map to destination fields automatically, by name and type. Wildcard flows map each matched object to its counterpart without a mapping per table.
Ask Simba for the rest
Open Simba, our AI agent, from any mapping editor — flat, nested, or X12 — and describe what you want. It handles renamed columns and casing, and you iterate until it is right.
Nested shapes, either direction
Nested mapping covers any shape on either side: flat to nested, nested to flat, nested to nested. JSON, XML, Avro, and Parquet read, written, normalized, and flattened.
Specifications
You choose how strict it is.
Handling schema changes is a setting on the transformation, not a global gamble. Pick the behaviour that suits the table, from “build whatever is missing” to “stop if a single column moved”.
Handling schema changes
Auto-Create & Match Target Table
Creates the table if missing, adjusts column types, excludes source columns the destination lacks. With Alter enabled, those columns are added instead.
Auto-Create Target Table, Fail on Mismatch
Creates when missing. Fails if the source has extra columns. Extra destination columns are allowed.
Match Existing Target Table, Do Not Create
Uses the table that is there and adjusts column types. Will not create a missing table.
Use Existing Target Table Without Modifications
Takes the table exactly as it is. The structure has to match or the flow fails.
Auto-Create & Strict Schema Match
Creates when missing. Otherwise names and column counts must be identical. Order and types do not matter.
Strict Schema Match, Do Not Create
Same strict rules, but fails immediately when the table is missing.
Switches worth knowing
Alter target table
Adds source columns the destination lacks · off by default
Recreate target table
Drops and rebuilds when the source has extra columns · destructive · off by default
Create indexes
Replicates a database source’s indexes onto the new table
Data Type Overrides
Source type → destination type, applied to every flow on the connection
Log DDL SQL statements
Writes every generated CREATE and ALTER to the flow log
FAQ
Common questions.
Will a schema change break my pipeline?
That is the situation this exists to prevent. Pick a handling mode per transformation and the flow behaves the same way every run: create what is missing, add the new column, ignore it, or stop and tell you. The default creates missing tables and matches types, and leaves altering off until you ask for it.
Does adding a column require me to edit the mapping?
No. Source fields map to destination fields automatically by name and type, so a new source column flows through once altering is enabled. You only touch the mapping when you want something other than the obvious answer.
What happens to tables that did not exist when I built the flow?
Use a wildcard for the source, for example
public.*, and the flow picks up objects matching the pattern on each run. Include and exclude lists narrow it, and matched objects can run in parallel.Can I control the generated DDL?
At two levels. Data Type Overrides map a source type to the type you want for every flow on that connection. Past that, you can override the generated CREATE and ALTER TABLE SQL with JavaScript, and log every DDL statement the flow executes.
Can a table be rebuilt when the schema changes?
Yes, and it is off by default because it is destructive. Recreate target table drops and recreates the destination when the source brings extra columns, which reloads the data. Prefer altering unless a rebuild is genuinely what you want.
Does this work for nested data too?
Yes. Nested mapping handles any shape on either side, so JSON, XML, Avro, and Parquet can be flattened into tables or written back out nested, and the same drift handling applies to the tables that result.
Start your trial
14 days. No card. Real workloads.
Point a flow at a table you know is going to change, and watch what happens on the next run.