Feature Matrix

How complete a migration is depends heavily on the source database. The table below shows the per-connector, per-feature status. It mirrors FEATURE_MATRIX.md in the repository, which is the authoritative version and is reconciled against the connector sources — every entry corresponds to code that is actually present, not to a plan.

Legend

#

The hardest part of raising a ? to a yes is usually finding a test database that actually uses the feature in a realistic way.

Support by connector

#

Column abbreviations: DB2 LUW / z/OS / i = IBM DB2 variants, MSSQL = MS SQL Server, SQL Any. = SQL Anywhere, Sybase = Sybase ASE.

Notes

#

1. IDENTITY columns (Oracle). Recognised via the sequence used as the default value. Data types remain an issue: Oracle allows a primary key on NUMBER with a sequence, while a PostgreSQL identity column must be INT or BIGINT.
2. Sequences. Not migrated as standalone objects for most engines. SERIAL/BIGSERIAL, identity columns and columns with a sequence default become PostgreSQL identity columns, so the sequence is created automatically and its current value is set from the migrated data afterwards. Oracle additionally migrates standalone sequences as independent PostgreSQL sequences (see note 7).
3. Check rules / domains. Externally defined checks bound to a column or data type — domains in PostgreSQL, rules in some other engines. Currently being implemented for Sybase ASE.
4. Sybase ASE defaults. CREATE DEFAULT creates a named default that can be attached to several columns. PostgreSQL has no equivalent, so the underlying default value is attached directly to each target column.
5. Sybase ASE computed columns. Sybase creates hidden computed columns for function-based indexes (e.g. sybfi4_1 AS LOWER(ProductName) MATERIALIZED), which also changes the index DDL stored in the system tables.
6. Implicit default replacements. Common default values whose syntax PostgreSQL does not accept are replaced implicitly during migration.
7. Oracle. Check constraints, standalone sequences, user-defined types, domains, table/column comments, views/materialized views and best-effort PL/SQL conversion are implemented but not yet validated against a live database. PL/SQL conversion is heuristic: packages are split into standalone <package>_<routine> functions with call sites rewritten (package state is not migrated), triggers become a PL/pgSQL trigger function plus CREATE TRIGGER, and complex constructs are flagged for manual review. Object types become composite types; collection types (VARRAY, nested tables) become array-based domains.
8. SQLite. SQLite has no data dictionary for several of these objects, so check constraints, generated column expressions, AUTOINCREMENT markers and functional index expressions are parsed out of the CREATE statements in sqlite_master. Views, triggers and expressions are translated with sqlglot plus a SQLite-specific function mapping. Partial indexes lose their WHERE condition (recorded in the index comment) and a partial unique index is degraded to a non-unique index. Virtual tables (FTS, RTREE, …) and their shadow tables are skipped. Because SQLite is dynamically typed, values are coerced to the target column type during data migration.
9. IBM DB2 z/OS and DB2 for i. These are offline connectors — they never connect to the source instance. Structure is read from .sql/DDL extracts (connectivity: "ddl") and data from source-generated CSV files. Anything requiring a live source (pre-migration analysis, random-sample and LOB-size validation) is therefore unavailable. COMMENT ON / LABEL ON statements are parsed out of the DDL and stored in the protocol tables, but are not yet applied to the target.
10. MySQL and MariaDB. Separate, largely identical connectors. MariaDB additionally migrates standalone SEQUENCE objects (MariaDB 10.3+). Neither converts functions, procedures or triggers.
11. SQL function mapping. Every connector ships a mapping of common source SQL functions to PostgreSQL equivalents, applied when defaults, views, constraints and routine bodies are converted. Coverage differs per engine and is extended on demand — hence WIP everywhere. No mapping is needed for a PostgreSQL source.
12. User-defined collations. Standalone CREATE COLLATION objects referenced by columns and indexes, migrated for a PostgreSQL source (ICU and libc provider, locale, tailoring rules, non-deterministic collations, comment). Collations of other engines (utf8mb4_general_ci, Latin1_General_CI_AS, …) have no PostgreSQL counterpart, so the reference is dropped and the column keeps the target database default.
13. Full text search objects. Dictionaries and text search configurations referenced by generated tsvector columns, views, indexes and functions. Migrated for a PostgreSQL source including the complete token type mapping; references inside 'name'::regconfig literals are rewritten. Objects belonging to an extension are not migrated — they come with the extension.
14. User-defined aggregates. CREATE AGGREGATE objects, migrated for a PostgreSQL source with their state transition, final, parallel and moving-aggregate support functions, initial conditions, sort operator and parallel safety. Created after the functions and procedures they reference. Aggregates provided by an extension are not migrated.

Tested database versions

#

Missing a source database or a feature you need? Support can be added on demand — see Get Involved.