An offline tool that isolates incompatibilities before migration

pgrecon stands out with its entirely offline approach: it never connects to the source (Oracle) or target (PostgreSQL) databases, according to the official PostgreSQL source. The tool begins with a read-only SQLPlus script, generating a reviewable extraction of Oracle schemas. This extraction serves as the basis for a deterministic rule engine applying 80 criteria covering data types, length semantics (such as converting VARCHAR2(30 CHAR) to varchar(30)), partitioning, PL/SQL constructs, or performance. The result is native PostgreSQL DDL for tables, constraints, indexes, views (including CONNECT BY hierarchies converted to WITH RECURSIVE), materialized views, comments, permissions, simple triggers, and autonomous routines.

A tool that silently estimates approximate cases for each complex scenario will always display a shorter rejection list than pgrecon.

A residue report to anticipate manual work

Unlike other tools that hide incompatibilities, pgrecon adopts radical transparency: every element that cannot be faithfully converted is listed in a residue report, with its name and the reason for the blockage, such as views using JSON_TABLE (requiring manual rewriting according to differences between PostgreSQL 17 and earlier versions), composite triggers (to be restructured into separate triggers), or columns using external file locators (with no direct equivalent in PostgreSQL), according to a technical article on dev.to. This report is designed to provide an accurate estimate of the manual work to be expected, thus avoiding surprises during migration. For example, Oracle packages (such as Alexandria) or views sorting by XMLTYPE are systematically excluded from automatic conversion.

Rigorous testing to ensure the reliability of conversions

The robustness of pgrecon relies on extensive automated testing. CI pipelines verify extraction against multiple Oracle versions (XE 11g, XE 21c, Free 23ai) and apply the converted output to PostgreSQL 16 and 17 (PostgreSQL 18 is mentioned as tested but without details on official support). A schema fuzzer generates 40 random Oracle schemas each night to ensure no crashes or silent data loss occur, following the technical details shared by PostgreSQL. The public benchmark, based on Oracle schemas such as HR, OE, and CO, as well as packages like utPLSQL or PLJSON, validates the conversion of 423 statements without rejection in version 0.7.3. These tests also cover length semantics (characters vs bytes) and objects like sequences or simple DML triggers.

What this changes here: a controlled migration for businesses and government agencies

For Beninese companies, government agencies, or organizations from West Africa using Oracle databases and looking to migrate to PostgreSQL, pgrecon provides a framework to assess technical feasibility before committing. Its residual report helps pinpoint the components requiring manual redesign, thus avoiding hidden costs. For example, an administration using complex hierarchical views (CONNECT BY) or autonomous triggers could estimate the time and resources needed to adapt them. Similarly, companies relying on Oracle packages (such as those for log management) could prioritize their migration based on their criticality. The tool, available via pip install pgrecon, serves as an essential preliminary step for critical migrations, where compatibility and traceability of incompatibilities are top priorities.