Oracle to PostgreSQL Database Migrations: Internals and Feature Mapping

A migration tool can convert your syntax, but it cannot tell you why the converted code behaves differently at runtime, and that gap is where Oracle to PostgreSQL projects quietly go wrong. The two engines make genuinely different choices below the SQL - Oracle keeps old row versions in undo segments and rolls forward from redo, while PostgreSQL keeps every version in the heap under MVCC and depends on vacuum to clean up, Transaction boundaries differ too, from AUTOCOMMIT and implicit commits to how a DDL statement behaves inside a transaction, and a NULL, an empty string, and a trailing space do not mean the same thing on both sides. This talk, drawn from a large number of real Oracle to PostgreSQL migrations, explains those internals first, because once you understand the engine the feature mapping stops being a lookup table and starts making sense.

The second half is a direct, feature-by-feature mapping of the things that actually come up in real migrations, each grounded in the internals from the first half. We will map sequences and identity, DATE and timestamp semantics, packages and PL/SQL to PL/pgSQL, autonomous transactions, global temporary tables, hierarchical queries, and the DBMS_ packages people assume have no equivalent until they do. For each one I will show the Oracle behavior, the PostgreSQL construct or extension that matches it, and the cases where the match is close but not exact, which is where the manual work and the production surprises live. You should leave being able to predict how a given Oracle feature will behave on PostgreSQL before you convert it, not after.