Cross-Database Schema & Table Migration Made Simple

Overview

Modern data infrastructure rarely lives in a single database engine. Teams routinely work across PostgreSQL, IBM Db2, MySQL, Oracle, and beyond — and moving data between them is one of the most tedious, error-prone tasks a database engineer faces. WizQl is a capability designed to eliminate that friction.

WizQl’s Transfer database feature allows you to select a source schema and one or more tables from a source database, then replicate that structure — along with its data — into a completely different target database engine. The system handles everything in between: schema creation, datatype mapping, and table creation. You bring the intent; WizQl handles the translation.

How It Works

WizQl’s Transfer Database operates in a structured, three-stage pipeline.

Stage 1: Source Selection

You begin by connecting to your source database and selecting:

• The schema — for example, public in PostgreSQL
• The tables within that schema — for example, account, orders, products

The system reads the source schema’s metadata: column names, datatypes, constraints, indexes, nullability, and default values. No data is moved yet — this is purely structural discovery.

Stage 2: Datatype Mapping

This is where WizQl does its most important work. Different database engines use different type systems. A TEXT column in PostgreSQL is not the same construct as a CLOB in Db2. A BOOLEAN in PostgreSQL has no direct native equivalent in older versions of Db2, where SMALLINT or CHAR(1) is conventionally used instead.

WizQl maintains a cross-engine type mapping table that translates source datatypes to their closest semantic equivalent in the target engine. The mapping is applied automatically, but can be reviewed and overridden before the migration is committed.

A few examples of how mappings work in practice:

Where no safe automatic mapping exists, it is the default TEXT type for the mapping is chosen.

Stage 3: Target Schema and Table Creation

Once the type mapping is resolved, WizQl creates the target environment from scratch:

1. Schema creation — A schema with the same name as the source is created on the target database. If a schema named public exists in your PostgreSQL source, a schema named public is created in Db2.
2. Table creation — Each selected table is created inside that schema, using the mapped column definitions, constraints, and indexes translated to the target engine’s DDL syntax.
3. Data transfer — Rows are read from the source tables and inserted into the target tables, with value-level transformations applied where necessary (for example, converting PostgreSQL TRUE/FALSE boolean values to Db2’s 1/0 convention).

A Concrete Example

Suppose you have the following table in PostgreSQL:

-- Source: PostgreSQL, schema: public
CREATE TABLE public.account (
    id          SERIAL PRIMARY KEY,
    username    VARCHAR(100) NOT NULL,
    email       TEXT NOT NULL,
    is_active   BOOLEAN DEFAULT TRUE,
    created_at  TIMESTAMP DEFAULT NOW()
);

You select schema public and table account, and target IBM Db2.

WizQl will:

1. Create the schema public in Db2 if it does not already exist.

2. Generate and execute the following DDL on the target:

   -- Target: IBM Db2, schema: public
   CREATE TABLE public.account (
       id          INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
       username    VARCHAR(100) NOT NULL,
       email       CLOB NOT NULL,
       is_active   SMALLINT DEFAULT 1,
       created_at  TIMESTAMP DEFAULT CURRENT_TIMESTAMP
   );

3. Transfer all rows from the source public.account table into the newly created public.account table in Db2, converting boolean values to 0/1 and adjusting any other value representations as needed.

Key Capabilities

Automatic Schema Mirroring

Source schema names are preserved on the target database. This makes it straightforward to maintain naming consistency across environments and avoids having to manually re-configure downstream applications that reference schema-qualified table names.

Multi-Table Selection

You are not limited to transferring a single table. You can select any subset of tables from a source schema in a single operation. WizQl respects foreign key dependencies and, where possible, orders table creation to avoid constraint violations.

Conflict Resolution

If the target schema or table already exists, WizQl detects the conflict and automatically appends to the existing schema or table.

Supported Database Engines

WizQl currently supports migrations between all the databases.

When to Use WizQl

WizQl is well-suited for the following scenarios:

Database engine migrations — Moving a production application from one database vendor to another, whether for cost, licensing, performance, or vendor requirements.

Environment replication — Copying a subset of production schemas and tables into a development or staging environment running a different database engine.

Data lake and warehouse seeding — Populating a new analytics database with operational data from a transactional system running on a different engine.

Cross-team data sharing — Providing another team access to a copy of specific tables in the database engine they already use, without requiring them to adopt your stack.

Limitations and Considerations

WizQl handles the vast majority of standard relational structures cleanly, but there are a few areas where manual attention may be required.

Engine-specific features — Stored procedures, triggers, views, and custom functions are not transferred. These are deeply engine-specific and require manual porting.

Complex indexes — Standard B-tree indexes are transferred where supported. Specialized index types (for example, PostgreSQL’s GIN or GiST indexes for full-text search) are flagged as unsupported and tried to be encoded as TEXT or skipped entirely.

Large objects — Very large BLOB or CLOB values may require tuned batch sizes and network configuration to transfer reliably.

Encoding differences — Character encoding mismatches between source and target (for example, UTF-8 vs. EBCDIC in legacy Db2 environments) may cause transfer failures.

Summary

WizQl removes the manual, error-prone work of cross-database migrations by automating the three steps that consume the most engineering time: reading source structure, translating datatypes, and generating target DDL. By preserving schema names, mapping types intelligently, and giving you a full preview before any changes are committed, it provides both automation and control.

Whether you are migrating a single table from PostgreSQL to Db2 or replicating an entire operational schema into a different engine for analytics, WizQl gives you a repeatable, auditable process that scales with your data.