We Ran Five Oracle-to-PostgreSQL Converters Against the Same Live Database. Only One Had Zero Errors.
Nine schemas, five tools, one PostgreSQL 16 database, and a definition of “error” nobody gets to argue with: a statement PostgreSQL itself rejects.
Every Oracle-to-PostgreSQL converter claims to convert your schema. Almost none of them tell you what happens when you actually run the output against a real database. So we did it for them.
Over the last two weeks we took nine Oracle schemas — Oracle’s own HR, OE, and CO sample schemas, four well-known open-source PL/SQL projects (utPLSQL, PLJSON, Logger, and Alexandria), and two lab schemas built to be nasty on purpose — and ran every one through five Oracle-to-PostgreSQL converters, including pgrecon, the tool my cofounder Muzzammil has spent the year building. Then we took every tool’s output and applied it, statement by statement, to a live PostgreSQL 16 database.
An error, in this benchmark, has exactly one definition: a statement PostgreSQL itself rejects. Not a missing feature. Not a stylistic complaint. A CREATE, an ALTER, or an INSERT that the target database refuses to run. That’s a low bar and a hard one — it’s the same bar a real migration hits in production, whether a tool warned you about it or not.
The numbers
Two of those deserve a sentence each. Ora2Pg’s output file carries a directive that stops the whole load at the first error — understandable behavior for a tool that expects you to fix things as you go, but it meant we had to remove that directive and pre-create an extension its output silently assumes, just to see the real count underneath. EDB Migration Toolkit’s number is generous to it: for a schema with 49 packages, it emitted exactly one statement — CREATE SCHEMA — and printed a success message. Zero attempts reads a lot like zero errors if nobody checks.
What “zero” doesn’t mean
It doesn’t mean pgrecon converts everything. Across the nine schemas, about half of all objects converted mechanically — above 90 percent on schemas shaped like a normal business database, well below that on the two schemas that exist to showcase Oracle object types and PL/SQL packages, which is exactly the part nothing converts mechanically yet. The gap is real, and it’s named: every object we didn’t convert shows up as one line in a residue report, with a reason, instead of silently vanishing or shipping broken.
That’s the part of this benchmark that actually matters. A tool that emits nothing invalid but also converts nothing would score zero errors too — the number only means something next to how much got attempted. Which is why we’re publishing the schemas, the tool versions, and the method, not just the table.(https://muzzammil242.github.io/pgrecon/benchmark.html)
If a number in there looks wrong to you, that’s a fair reaction — reproduce it. The schemas are public, the tool versions are named, and pgrecon’s own conversion output gets applied to a live PostgreSQL database before every release, not just for this post.
pgrecon is Apache-2.0 and free to run: https://github.com/Muzzammil242/pgrecon has the install command, the full write-up, and the source. If Oracle costs are on your organization’s roadmap this year, a fixed-price assessment is the cheapest way to find out what a real migration would cost — book one at DevCrafter AI.
