Benchmark methodology
six converters, nine schemas, one live PostgreSQL 16

Back to pgrecon GitHub

The question and the bar

Every converter claims to convert an Oracle schema. The benchmark asks one narrower question: when the tool's output is applied to a real PostgreSQL, statement by statement, how many statements does PostgreSQL itself reject? An error here is not a missing feature or a style complaint - it is a statement the target database refuses. That is the same bar a real migration hits in production, whether a tool warned about it or not.

A zero on that bar does not mean everything converts, and the number only means something next to how much was attempted; the coverage numbers are stated below with the same precision as the error counts.

The nine schemas

• Oracle's official sample schemas HR, OE, and CO (db-sample-schemas v21.1; OE is the object-relational showcase).
• Four well-known open-source PL/SQL projects, installed from their own repositories: utPLSQL (UT3), PLJSON, Logger, and Alexandria - package-heavy by nature.
• RECON_TEST, a synthetic estate built to be nasty on purpose - interval partitioning, package state, compound and autonomous triggers, LONG, XMLTYPE, a db link, a materialized view. It ships in this repository at tests/fixtures/synthetic/synthetic_schema.sql.
• One further private lab schema (heavy DDL surface: a datatype zoo, wide grants, synonyms). It is not redistributable, so the reproduction kit below covers eight of the nine schemas; every tool ran against all nine under identical conditions.

Source database: Oracle XE 21c (21.3), loaded with all nine schemas. Target: a stock postgres:16 container. No compatibility extensions installed unless a tool's own output requires one, in which case that is recorded below.

Two rows were measured later than the August round, in GitHub Actions with the same image and the same eight public schemas, the private lab schema excluded: pgrecon at 0.7.3 on 2026-10-05, and Dalibo's PostgreSQL Migrator 1.0.0 on 2026-09-19. The pgrecon run, its logs, and its SQL are public; the Dalibo run was a private one-off, and its job definition, log, and SQL are available on request.

Tools and versions

How errors were counted

Each tool's generated SQL was applied to a fresh database in the same PostgreSQL 16 with psql -qX and ON_ERROR_STOP off, so every statement gets its chance; the error count is the number of lines PostgreSQL answered with ERROR. Function bodies were applied with check_function_bodies on wherever the tool's own output did not override it. Where a tool emitted per-schema files they were applied in the tool's own recommended order.

Per-tool accommodations

Runs were kept as fair as each tool allows; everything a tool needed beyond its documentation is recorded here.

• pgrecon: none. The output applied as emitted.
• Ora2Pg: two. Its output sets ON_ERROR_STOP inside itself, so as shipped it stops at its own first error (OE stopped at statement 29); the self-abort was stripped to measure the full count. Its SYS_GUID mapping silently requires the uuid-ossp extension, which was pre-created.
• CYBERTEC ora_migrator: one environment fix (a libaio symlink for the instant client on Debian 13). Two schemas - utPLSQL and the private lab schema - crashed whole in db_migrate_prepare on the staging schema's own foreign keys and were never attempted; they are counted as crashes, not errors. PL/SQL is out of its scope by design and is not counted against it.
• Dalibo PostgreSQL Migrator: one. Its inspection reported 20 errors on object-relational and nested-table shapes in OE and utPLSQL and declined to convert; the dump was forced with its documented --force option, which is its own partial-migration path. Nothing else was changed. Version 1.0 marks views, materialized views, routines, packages, triggers, types and partitions as partially implemented, and none of them reached its schema-only dump, so its row is tables, sequences, indexes, keys and checks. Its PL/SQL parser could not read 16 package bodies of the corpus; those are counted as absence, not as errors. One of its rejected statements is PostgreSQL 17 syntax sent to the benchmark's PostgreSQL 16. Data copy and the web UI, its strongest parts, are outside this benchmark's question.
• EDB MTK: applied from its combined per-schema file only (its per-class files repeat the same statements; applying both would double-count). Its number is generous: for one schema with 49 packages it emitted a single CREATE SCHEMA - 51 bytes - and reported success. Across nine logs its only unsupported-feature message was INTERVAL partitioning, twice; packages and object types vanished without a word.
• AWS SCT: applied without its aws_oracle_ext runtime extension - the portability question a client actually faces. Its converted routines create cleanly (PostgreSQL only syntax-checks function bodies) and depend on that extension when called; the count reflects statements rejected at apply time.

Results

Coverage, stated with the same precision. At 0.7.3 on the eight public schemas (2026-10-05, in CI): 594 objects the converter is answerable for - tables, views, materialized views, sequences, synonyms, routines, triggers, indexes, and constraints - of which 241 were created in the emitted DDL, 41 percent; 353 were declined by name in the residue report; none were lost. Above 95 percent on HR and CO, 76 percent on RECON_TEST, 81 percent on Logger, 40 percent on OE, whose object types nothing converts mechanically, 25 percent on utPLSQL, 4 percent on PLJSON, and none on Alexandria, which is almost entirely packages; on those three the residue points at the package flattener. The August round, all nine schemas and a count over every object, put the figure at 51 percent. One hierarchical view was additionally verified row-for-row against the live Oracle running the original.

The other tools' outputs are unchanged from their August runs; none of them has released a new version since. Between full runs the converter is guarded by CI, which applies its output to PostgreSQL 16, 17, and 18 on every commit and fuzzes it nightly against adversarial schemas.

Reproduce it

podman run -d --name oracle-xe -e ORACLE_PASSWORD=... gvenzl/oracle-xe:21
podman run -d --name pg-target -e POSTGRES_PASSWORD=... postgres:16
# install HR/OE/CO from db-sample-schemas v21.1, the four projects
# from their repositories, RECON_TEST from this repo's fixture
pip install pgrecon==0.7.3      # the version the pgrecon row was measured with
pgrecon script            # extraction script; run per schema via sqlplus
pgrecon load dump_dir --db est.db
pgrecon convert --db est.db
psql -qX -f schema_pg.sql 2>&1 | grep -c ERROR:

Or fork the repository and run its Benchmark workflow from the Actions tab: it starts Oracle XE 21c and PostgreSQL 16 inside the job, installs the eight public schemas, extracts, converts, applies, and prints the table above with the count of statements rejected and the coverage per schema. That is how the 2026-10-05 numbers were produced, and the run, its logs, and every dump, DDL file, and residue report it made are public.

Run each competing tool per its own documentation against the same schemas, apply with the same psql invocation, count the same way. If a number here looks wrong, that is a fair reaction - reproduce it and say so on the issue tracker.