Data Transfer

Data Transfer copies tables or collections from one source into another connection, database, or schema. Use it for environment migration, test data preparation, and one-off consolidation. It is not continuous replication, CDC, or bidirectional synchronization.

Cross-engine transfer passes through DBX field and type conversion. Target privileges, constraints, triggers, defaults, and engine semantics still determine the result. Rehearse important migrations and validate row counts and key fields afterward.

Two Entry Points

Data Transfer Wizard

The wizard is designed for multiple tables. Select the source and target connection, catalog, database, and schema, then configure table creation, write mode, target-name case, and batch size.

After copying one or more tables in the object tree, paste them at a target location:

Within the same context, choose structure and data, structure only, or data only, and edit each target name
Pasting into another connection, database, or schema opens the Data Transfer wizard with the source tables and target prefilled
Whole-row copy excludes generated or computed columns and applies path-specific handling for PostgreSQL identity and SQL Server identity columns

Wizard Workflow

Select the Source

Choose the source connection, catalog when applicable, database, and schema. DBX lists transferable base tables; MongoDB paths list collections.

Select the Target

Choose another connection, database, or schema. Source and target cannot be the exact same location.

Choose Tables

Select all, search, or choose a subset. A single request can only contain tables from one source context.

Configure Options

Review target-table creation, write mode, target-name case, and batch size.

Run in Background and Review

The task keeps running after the dialog closes. The progress center reports the current table, table index, rows, duration, failed tables, and cancellation state.

Transfer Options

Option	Details
Create target tables	Generates target structure from source metadata when the table does not exist and the path supports it
Append	Keeps existing target rows and inserts source rows
Overwrite	Clears each target table before writing its source rows
Upsert	Updates or inserts by key when the target path supports it and a usable key is available
Target table name case	Preserve, lowercase, or uppercase; transformed target names must remain unique
Batch size	Controls paged reads and batched writes; the UI default is 1000

If table creation is disabled, compatible target tables must already exist. Even with table creation enabled, cross-engine DDL may require manual changes when the target does not support a source type, default, constraint, or object.

PostgreSQL Structure and Ownership

For PostgreSQL-to-PostgreSQL transfers with table creation enabled, DBX handles supported sequences, indexes, foreign keys, and selected schema-level objects and dependencies. If source owners do not exist on the target instance, DBX prompts you to:

Skip the affected ownership metadata
Reassign missing owners to the current target user
Cancel and create the required target roles first

This is not a full replacement for pg_dump and pg_restore. Use native PostgreSQL tooling when extensions, grants, policies, triggers, or dependency graphs are complex.

Failure Handling

A multi-table task does not discard the entire queue after the first table failure. DBX records the failure, attempts later tables, and finishes either successfully or with a terminal error summary.

Progress keeps per-table failure details
When failures exceed the display limit, the UI reports how many entries were omitted
A new task is rejected if another active transfer already targets the same table
Cancellation stops later reads and writes, but committed target data is not automatically reverted

As a result, a finished task does not necessarily mean every table succeeded. Check the terminal state, failure list, target row counts, and key fields.

Database Coverage

DBX filters source and target connections through the driver capability manifest. The implementation includes SQL-to-SQL, MongoDB-to-MongoDB, and selected MongoDB/SQL conversion paths. Not every connectable database supports Data Transfer.

Capabilities also vary by combination:

Some engines transfer rows but cannot reuse source DDL
Upsert depends on the target engine and discoverable keys
Catalogs, schemas, identity columns, arrays, JSON, and binary values are engine-specific
Specialized search, vector, message queue, and configuration-center connections do not use this generic table-transfer entry point

If a connection is absent from the selector, its current driver has not declared Data Transfer support; it is not merely a hidden UI action.

Before Transferring

Check whether the target connection has read-only protection; read-only targets are blocked
Confirm source read privileges and target create/write privileges
Check for target-name collisions after case conversion
Review primary keys, unique constraints, foreign keys, triggers, and required fields
Decide whether production data must be masked before entering a lower environment
Use native export/import or online migration tools when the dataset is too large for an interactive transfer