🛢
Propagate project options
All your rules are applied to all tables automatically.
See how it works →Extensive Customization
Defaults you almost never change. Project-wide rules for when you do. Per-table overrides for the one table that's different from all the others. Granular when it counts.
CustomizationSet the common rule once. Override the exception precisely.
Omni Loader
Name rule
snake_caseText width
adaptiveWorkers
auto ordersTABLE OVERRIDE
workers: 8filter: active order_id
bigintcustomer_note
textcreated_at
timestamptzRules that stay usable
Set the baseline. Refine the exception.
Use project-wide rules for the common path, then scope a mapping, naming, filtering, or loading override to the table that needs different treatment.
Project Options
One place to set the rules that apply to every table: Conversion, Performance, Mapping, Databases, Logging, and Troubleshooting. Set once, applied everywhere.
Table Options
That one giant table that needs special handling? Override the project rules just for it. The other 200 tables don't have to care.
⚡
Filter your data
Specify your own custom filter SQL expressions.
See how it works →⤢
Preview target DDL
See the exact create table statement for the target database.
See how it works →The exception-management problem
The defaults are right. Until one table proves they are not.
Most of a migration should be boring. Names map predictably, ordinary types take the fast path, and hundreds of tables follow the same project rules. Then the exceptions appear: a legacy name the target cannot keep, a table that needs filtering, an existing target contract, a type with business meaning, or a distribution choice that changes query performance.
The wrong response is to make every table manual. The other wrong response is to force the exception through a global rule and quietly change objects that were already correct.
Define the common policy once, make exceptions at the narrowest useful scope, and keep every departure from the baseline visible and reviewable.
You are here when…
The old plan stops being credible.
The target has its own conventions
Schema names, table names, column names, or types must match an established platform contract rather than mirror the source literally.
Some data should not move
A table requires a source-side filter, a subset of rows, or a deliberate selection rule tied to the migration scope.
One object needs a different physical design
An oversized table, existing target, partitioning scheme, or warehouse distribution strategy needs treatment that should not affect the rest of the project.
Before
Before: choose between a black box and a bespoke project
Automatic tools move quickly until the first exception. Scripted tools handle anything but require every table to become an exception. Teams end up maintaining parallel configuration paths and hoping the global and custom logic still agree.
After
After: policy at project scope, precision at table scope
Set conversion, performance, creation, mapping, and logging behavior once, then let ordinary tables inherit it. Switch only the exceptional table to manual control for names, types, filters, existing-target links, or partitioning, and preview the target DDL before rows move.
Use this capability when
The situation, not the feature list, says yes.
✓ The target must conform to naming, type, or schema standards that differ from the source.
✓ A small subset of tables needs filters, repartitioning, or existing-target mapping.
✓ Business meaning requires a deliberate type or default-value decision.
✓ You need reviewers to see exactly where the migration departs from the shared policy.
Progress you can see
A smaller configuration surface
Common behavior lives once at project scope instead of being copied across hundreds of objects.
Visible exceptions
Table-level choices stand out as deliberate contracts that can be reviewed and tested independently.
Fewer accidental side effects
Change the table that differs without weakening the baseline for every table that does not.
Customization should make the migration more understandable, not more mysterious.
The goal is not infinite knobs. It is the narrowest useful place to express a real business rule, with a generated target contract the team can inspect before execution.
Save time. Get the job done.
Bring a real source and target. We'll scope the migration and show you live throughput on your data.