Skip to content
adapters.io

Oracle to PostgreSQL migration tools compared: Oracle database migration tools, converters, and what a migration really costs

Twelve tools that move an Oracle database to PostgreSQL, lined up by whether they convert code, move rows, or only pretend to do both. The part that decides your timeline is not on any feature list: AWS publishes an automation rating for every Oracle feature area, and two of them are rated no automation at all. That table, the conversion defaults that ship a schema which deploys and misbehaves, and the real platform limits are all below.

Try the live demo

No credit card required.

Field mapping auto-plugged · tap a port to rewire

5 sample records ready

Vendor documentation read 30 August 2026 · Last updated September 2026

Which Oracle to PostgreSQL migration tool should you use?

Use two tools, because this is two projects. For converting the schema and the PL/SQL, start with Ora2Pg, which is free and produces a person-day estimate, or DMS Schema Conversion if you are heading for RDS or Aurora and want the assessment report in the console. For moving the rows with a short cutover, use AWS Database Migration Service into AWS, Google Cloud Database Migration Service into Cloud SQL or AlloyDB, and Qlik Replicate or Striim if the sources are varied and the Oracle instance is staying online. If the Oracle schema is so deep in PL/SQL that a rewrite is not realistic, EDB sells Oracle compatibility instead, which is a different decision from a migration. And if the old system does not actually switch off, which happens more often than anyone plans for, you are buying an ongoing integration rather than a migration.

The correction worth making early: nearly every page in this category ranks tools by how much of the schema they convert, quoted as a percentage. That number is close to meaningless, because most objects in any Oracle schema are ordinary tables that everything converts. The number that predicts your schedule is the count of packages, procedures and triggers on the exception list. For the wider category, see data migration tools, and for the ongoing case rather than the one-time move, Postgres ETL tools.

Oracle to PostgreSQL migration tools compared

Pricing models rather than price tags, because every vendor here except us either quotes or meters, and any figure printed on this page would be stale within a quarter. Where a tool is wrong for a job, the last column says so.

Tool Owner Approach Best for Pricing model Watch out for
AWS DMS Amazon Web Services Managed replication instance: full load, then log-based change capture from Oracle redo Moving Oracle into RDS or Aurora PostgreSQL with a short cutover window Per hour of replication instance, plus storage and data transfer Rejects identifiers over 30 bytes during change capture, whatever your Oracle version allows
DMS Schema Conversion Amazon Web Services Converts schema and PL/SQL, produces an assessment report listing what it could not convert Sizing the code rewrite before you commit to a date No license charge, you pay for the infrastructure it runs against Several conversion defaults change behavior silently. Read them before you accept the output
Ora2Pg Open source, GPL-3.0 Perl tool that scans an Oracle schema and emits PostgreSQL DDL, data and converted code Any migration, and the standard first step for scoping one Free Its own documentation calls the PL/SQL conversion basic and says the output must be reviewed
Google Cloud DMS Google Cloud Managed heterogeneous migration into Cloud SQL or AlloyDB for PostgreSQL, with a conversion workspace Landing an Oracle estate in Google Cloud rather than AWS Heterogeneous migrations are charged, homogeneous ones are not Hard caps: 10,000 tables per job, 30-character names, and rows above 100 MB are dropped as errors
Azure DMS Microsoft Managed migration service into Azure Database for PostgreSQL, paired with Azure Data Factory for orchestration Estates already standardized on Azure Service tiers plus the compute the migration runs on Oracle sources have historically had narrower support here than SQL Server sources
EDB EnterpriseDB Oracle-compatible PostgreSQL distribution plus a migration portal that assesses schema compatibility Schemas so deep in PL/SQL that a rewrite is not viable Subscription, quoted per deployment Compatibility is bought, not free. You are choosing a commercial Postgres over community Postgres
Qlik Replicate Qlik Log-based change capture across many source and target engines, including Oracle to PostgreSQL Enterprises replicating from several legacy sources at once Subscription, quoted Moves data well and does not convert procedural code at all
Striim Striim Streaming change capture with in-flight processing between Oracle and PostgreSQL Continuous replication where the Oracle instance is staying online long term Subscription, quoted by capacity Priced for a streaming platform, which is heavy if all you need is one cutover
Debezium Open source, Apache 2.0 Kafka Connect change capture with an Oracle connector reading redo logs Teams that already run Kafka and want the events, not just the table Free, you operate Kafka and Kafka Connect yourself The Oracle connector is the most operationally demanding one Debezium ships
Fivetran Fivetran Managed ELT that replicates Oracle into a warehouse or database target Analytics replication rather than an application cutover Monthly active rows, transformations metered separately A one-time historical backfill can produce an unusually large first invoice
Informatica Informatica Enterprise data integration with lineage, governance and mass ingestion Regulated migrations that must produce audit evidence Consumption units, quoted annually Procurement and enablement are measured in months, not days
Adapters Adapters Field-level mapping between apps and databases, run on a schedule with retries and per-record logs The sync that has to keep running after the migration, or alongside a long parallel run Flat monthly price, not metered by rows We do not convert PL/SQL and we do not read Oracle redo logs. Use a converter for that half

Oracle publishes a global price list as a dated PDF and revises it through the year, and the licensing metrics that matter are Processor and Named User Plus rather than a single sticker price. We are not printing an Oracle figure here, because a license number quoted second hand is the fastest way to build a business case on something untrue. Get the current list from Oracle directly, or from the reseller handling your renewal. Our own price is flat and published, which is why ours is the only number on this page.

What converts automatically, and what you rewrite by hand

AWS publishes an automation rating for every Oracle feature area in its Oracle to Aurora PostgreSQL migration playbook, on a five-level scale from full automation down to no automation. It is the most useful public estimate of migration effort that exists, and almost nobody reads it. Summarized below from the AWS action code index, read 30 August 2026. Two areas are rated no automation at all.

Feature area Automation What converts What you do by hand
Creating tables High Names, columns, basic types, constraints, primary and foreign keys convert automatically Object tables, clustered tables, external tables, global temporary tables
Data types High Syntax is similar enough that most types convert without intervention ROWID, UROWID, BFILE, nested tables, VARRAY of VARRAY, multi-dimensional arrays
Indexes High Ordinary non-clustered indexes migrate automatically Bitmap indexes, domain indexes, functional indexes over more than one column
Views High The basic CREATE VIEW syntax is close to identical PIVOT, WITH READ ONLY, object views, typed views, view constraints
Flow control High Loops, blocks and delays convert cleanly GOTO and conditional compilation
Transaction isolation High All four SQL:92 isolation levels convert, as do BEGIN, COMMIT and ROLLBACK SAVEPOINT and ROLLBACK TO SAVEPOINT inside routines
OLAP functions High PostgreSQL supports almost all of them natively GREATEST and LEAST are flagged as possibly returning different results
SQL Medium Common statements convert, both engines meet entry-level ANSI BULK COLLECT, dynamic SQL, synonyms, FOR UPDATE SKIP LOCKED, MODEL, GROUPING SETS
Stored procedures Medium PostgreSQL functions cover most Oracle procedure behavior Java stored routines, TABLE functions, DBMS_SQL, functions with OUT and INOUT parameters
Triggers Medium BEFORE and AFTER triggers on INSERT, UPDATE and DELETE map over COMPOUND TRIGGER, FOLLOWS and PRECEDES, system triggers, conditional predicates
Cursors Medium PL/pgSQL cursors cover the ordinary iteration patterns REF CURSOR declarations, global cursors, cursor attributes, SQLCODE and SQLERRM outside a handler
User-defined types Medium Standard user-defined types are replaced by their base types Associative arrays, collection constructors, FORALL, member functions
Sequences Medium Oracle IDENTITY and PostgreSQL sequences reconcile despite different syntax Sequence statuses, and the starting value, which defaults to the initial value not the current one
Partitioning Medium PostgreSQL partitioning is richer than Oracle, including hash and sub-partitioning Null partition keys, foreign keys touching partitioned tables, partition-level updates
Query hints Medium Basic index hints convert outside DML Everything else. AWS advises starting with all hints removed
Materialized views Low Converted, but incremental refresh and DML on them are not supported Refresh strategy, and the default that turns them into plain tables
MERGE None AWS states MERGE cannot be converted automatically at all Every MERGE statement, by hand. Smaller than it sounds: PostgreSQL 15 and later support MERGE natively
Database links None AWS states this requires a full rewrite of the mechanism Every cross-database call, reimplemented on postgres_fdw or in the application

Read the bottom of that table first. MERGE and database links carry no automation, which means every occurrence is hand work, and database links in particular are described by AWS as needing a full rewrite of the mechanism rather than a translation. The Ora2Pg project is equally direct about its own output: it describes the PL/SQL to PL/pgSQL conversion as basic and states that generated code for functions, procedures, packages and triggers has to be reviewed to match PostgreSQL syntax. Neither vendor is overselling here, which is more than can be said for the summaries built on top of them. The construct-by-construct version of this, with the specific action codes, is in converting Oracle PL/SQL to PostgreSQL.

Eight failures that report success

An Oracle migration rarely fails loudly. It converts cleanly, deploys cleanly, and is wrong. Every row here comes from vendor documentation rather than folklore, and several of them are simply the default setting doing exactly what it is documented to do.

Failure What you see Cause The check that catches it
Materialized views stop refreshing Schema deploys cleanly, reports look right on day one and go stale after DMS Schema Conversion converts Oracle materialized views to plain TABLE by default Set MaterializedViewConvert to MATERIALIZED_VIEW, then confirm each one has a refresh
Primary key collisions on the first insert Cutover succeeds, then the application throws duplicate key errors within minutes Converted sequences start at their initial value by default, not the last value used on the source Turn on the setting that carries the last generated value across, then read back each sequence
Objects that compile and do nothing The whole schema deploys with no errors at all Unsupported built-ins can be replaced by stub objects with the same signature, which compile Keep stubs in a separate schema and treat that schema as an open work list
Cents disappear from NUMBER columns Row counts match exactly, money totals do not Optimized NUMBER mapping picks SMALLINT, INTEGER or BIGINT from observed precision and scale Sum every money column on both sides to the cent before you sign off the load
A full load that reports completed but is not Task status shows completed, the target is short of rows AWS documents that if the Oracle source becomes unavailable mid load, the task may be marked completed anyway Compare row counts per table against the source. Never trust the task status alone
Long CLOB updates lost in flight No error, the target row simply keeps the old value On Oracle 11 with LogMiner, an update to a CLOB longer than 1982 characters is lost Move to Binary Reader for LOB-heavy schemas, or validate CLOB columns explicitly
Tables silently excluded by name length Some tables never appear in the target and the job stays green AWS caps identifiers at 30 bytes during change capture, Google caps names at 30 characters Run LENGTHB on every object name before you start, not after
GREATEST and LEAST return different answers Code converts at the highest automation rating and results differ AWS flags both functions as possibly producing different results than the Oracle source Diff the output of every report that uses them against the Oracle original

Three of those eight are conversion defaults rather than bugs. Materialized views become plain tables, sequences restart at their initial value, and unsupported built-ins can be replaced by stubs that compile. A team that accepts the generated DDL without opening the settings page gets all three, and gets a schema that deploys without a single error. The same pattern across other platforms is in data migration tools and change data capture tools.

The limits that decide the plan

30 bytes

AWS DMS identifier limit during change capture, regardless of Oracle version

AWS DMS documentation, read 30 Aug 2026

10,000

Tables per Google Cloud DMS migration job

Google Cloud documentation, read 30 Aug 2026

100 MB

Google Cloud DMS row size ceiling. Larger rows are not migrated and surface as errors

Google Cloud documentation, read 30 Aug 2026

2

Feature areas AWS rates as no automation at all: MERGE and database links

AWS Oracle to Aurora PostgreSQL playbook, read 30 Aug 2026

5 min

Ora2Pg default cost unit, explicitly assuming a PostgreSQL expert does the work

Ora2Pg documentation, read 30 Aug 2026

1982

CLOB length above which an update is lost on Oracle 11 with LogMiner

AWS DMS documentation, read 30 Aug 2026

The 30 limit is the one that catches good teams. Oracle raised its own identifier limit to 128 characters in 12.2, so a schema designed since then can be full of names that are perfectly legal in Oracle and that neither AWS nor Google will replicate. AWS measures the limit in bytes rather than characters, so a name using multibyte characters can breach it well short of 30 characters. Check with LENGTHB before the project starts, because renaming objects is easy in week one and political in week twelve.

How to migrate Oracle to PostgreSQL in six steps

  1. 01

    Run an assessment before you promise a date

    Point Ora2Pg or DMS Schema Conversion at the source and read the report, not the summary. What matters is the count of objects the tool says it cannot convert, broken down by type. That number is the project. Note that Ora2Pg estimates in person-days using a default of five minutes per cost unit, and its documentation states that five minutes assumes a PostgreSQL expert. If your team is learning PostgreSQL on this project, the estimate is optimistic by construction.

  2. 02

    Fix the object names first

    Both AWS and Google cap identifiers at 30, AWS in bytes during change capture and Google in characters. Modern Oracle allows far longer names, so a schema built after Oracle 12.2 can be full of identifiers no migration service will replicate. Run LENGTHB over every table, view, column, constraint and key name in scope, and rename the offenders in Oracle while both sides still agree.

  3. 03

    Convert the schema, then read the defaults

    Accepting the converted DDL without reading the conversion settings is where the silent failures come from. Decide explicitly whether materialized views stay materialized, whether sequences continue from the source value, whether unsupported built-ins become stubs, and how NUMBER is mapped. Four settings, each of which produces a schema that deploys perfectly and behaves differently from Oracle.

  4. 04

    Rewrite what no tool converts

    MERGE statements and database links have to be rewritten by hand, because AWS rates both as no automation. Autonomous transactions, BULK COLLECT, FORALL, associative arrays and DBMS_SQL follow close behind. Do this work against a real PostgreSQL instance with real data, not against the assessment report, because the failures are behavioral rather than syntactic.

  5. 05

    Full load, then change capture, then a short cutover

    Put the source in ARCHIVELOG mode and enable supplemental logging at the database level and on each replicated table, or the change capture phase has nothing to read. Run the full load, let the change stream catch up until lag is near zero, then stop writes for seconds rather than hours while the last changes drain.

  6. 06

    Validate on totals, not on job status

    Count rows per table on both sides. Sum every money and quantity column to the cent. Check the minimum and maximum of every date column, which catches a timezone shift immediately. Then read back every sequence. AWS documents a full load that can report completed while the target is short, so the job status is not evidence.

Who runs this migration, and why

Escaping an Oracle renewal

The commonest reason this project exists. Oracle licenses by Processor or by Named User Plus, and the renewal is what funds the migration. The saving is real, and it lands a year later than the finance model assumed because the parallel run costs money on both sides.

Moving to Aurora or Cloud SQL

A cloud migration and an engine migration in one program. The conversion work is the same either way, because Aurora PostgreSQL and Cloud SQL for PostgreSQL are both PostgreSQL compatible. Choose the target on operations and lock-in, not on how the schema converts.

Keeping Oracle and reporting elsewhere

Not every project is a cutover. Plenty of teams keep Oracle as the system of record and replicate into PostgreSQL or a warehouse for reporting. That is an ongoing integration, priced as a subscription forever, not a migration with an end date.

A long parallel run

Regulated environments often run both databases live for months while the business validates. That period needs a sync that retries, alerts and logs per record, which is a different tool from the one that did the one-time load.

Retiring an application, keeping the data

The Oracle instance exists because one application needs it. When that application is replaced, the data still has to land somewhere queryable, and PostgreSQL is the usual destination.

Consolidating several Oracle schemas

Multiple Oracle databases collapsing into one PostgreSQL cluster. The migration mechanics are the same per source, and the hard part becomes reconciling identifiers and business rules that diverged over a decade.

The third and fourth of those are the ones that quietly become permanent. A reporting replica set up for a six-month parallel run is still running four years later, and by then it is an integration with an owner and a budget. If that is your situation, price it as a subscription from the start rather than discovering it later. The same reasoning applied to SQL Server is in SQL Server to PostgreSQL migration, and the third route off a commercial engine, where type mapping rather than procedural code decides the outcome, is on MySQL to PostgreSQL migration tools. The Microsoft route, where eight published type mappings do not survive a check against the documentation they point at, is on SQL Server to PostgreSQL migration tools. If the destination under consideration is a warehouse rather than another transactional database, the same Oracle source is compared against Snowflake in Oracle to Snowflake migration tools, where the licensing behind the first-party connector changes the shortlist.

Where Adapters is the wrong choice

We are a sync product, not a converter. On an Oracle migration that distinction rules us out of the hardest half of the work, and pretending otherwise would waste your evaluation time.

  • We do not convert PL/SQL. If your Oracle schema carries real procedural logic, the work is code conversion and you want Ora2Pg or DMS Schema Conversion, not us.
  • We do not read Oracle redo logs. For log-based change capture off Oracle, use AWS DMS, Qlik Replicate, Striim or Debezium.
  • We are not a certified partner in an Oracle procurement process. If your migration needs vendor-attested lineage for an auditor, Informatica is built for that and we are not.
  • For a single one-time load with no ongoing sync afterwards, a free tool plus a weekend is genuinely cheaper than any subscription, including ours.
  • If you need Oracle compatibility preserved rather than removed, EDB is the honest answer. We help after the schema is PostgreSQL, not before.

Four questions to ask any Oracle migration vendor

Ask how many objects the tool cannot convert, by type

Not the percentage converted, which is always flattering because most objects are simple tables. Ask for the count of packages, procedures and triggers on the exception list, because that count is the schedule.

Ask what happens to sequences at cutover

If the answer is not a specific setting name, the sequences will start at their initial value and collide with existing keys. This is the single most common day-one failure and it is a checkbox.

Ask whether the tool converts code or moves rows

Almost every vendor does one well and the other not at all. A replication product will move an Oracle schema perfectly and convert nothing. A conversion product will convert and never sync.

Ask what the parallel run costs

The period where both databases are live is usually the largest line item and is missing from most business cases. Price it in months of Oracle support plus the new platform, running at the same time.

Related migration and integration guides

Oracle is one route among several. These cover the neighbouring engines, the ongoing sync case, and the cost model behind a migration program.

Data migration tools

The pillar above this page: twelve tools, type mapping traps and cutover methods.

Convert Oracle PL/SQL to PostgreSQL

Construct by construct: what converts, what does not, and what converts wrongly.

SQL Server to PostgreSQL migration

The other big commercial-to-Postgres route, with its own type mapping table.

Postgres ETL tools

Once the data is in PostgreSQL, the tools that keep loading into it.

Change data capture tools

How the near-zero-downtime cutover actually works, across engines.

What a data migration really costs

Nine pricing models scored on how each behaves when the project overruns.

Questions buyers ask about Oracle to PostgreSQL migration

How do I migrate an Oracle database to PostgreSQL?
In two separate projects that people keep treating as one. First the schema and the code: tables, types, indexes, views, and every stored procedure, converted with AWS Schema Conversion, Ora2Pg or by hand. Then the data: a full load followed by change capture until the lag is near zero, so the cutover is seconds rather than a weekend. The code conversion is the part that overruns, because it is the part no tool finishes.
What are the best Oracle to PostgreSQL migration tools?
It depends which half of the problem you have. For schema and PL/SQL conversion, AWS DMS Schema Conversion and Ora2Pg are the two that most teams actually use, and Ora2Pg is free under GPL-3.0. For moving the rows with low downtime, AWS Database Migration Service, Google Cloud Database Migration Service, Qlik Replicate and Striim all do log-based capture. Most migrations use one tool from each group, not one tool for both.
Can Oracle PL/SQL be converted to PostgreSQL automatically?
Partly, and the vendors say so themselves. The Ora2Pg project describes its PL/SQL to PL/pgSQL conversion as basic and states that generated code for functions, procedures, packages and triggers has to be reviewed. AWS publishes an automation rating per feature area in its Oracle to Aurora PostgreSQL playbook, and two areas are rated no automation at all: MERGE statements and database links.
How long does an Oracle to PostgreSQL migration take?
Estimate from the number of stored procedures, not the number of gigabytes. Copying the rows is bounded work that a replication service does in hours or days. Rewriting packages that use autonomous transactions, BULK COLLECT, associative arrays and DBMS_SQL is unbounded work that depends on how much business logic ended up in the database. A schema with almost no PL/SQL can move in weeks. A schema with thousands of procedures is a multi-quarter program.
Is PostgreSQL compatible with Oracle?
Compatible enough for SQL, not for PL/SQL. Both engines support entry-level ANSI SQL, so ordinary SELECT, INSERT and CREATE TABLE statements move with little friction. The procedural language is a different story: PostgreSQL has no autonomous transactions, no packages, no synonyms, no ROWID, no MERGE in older versions and no database links without a foreign data wrapper. Extensions such as orafce close some of the gap by reimplementing Oracle built-in functions.
What data types do not convert from Oracle to PostgreSQL?
ROWID and UROWID have no PostgreSQL equivalent, BFILE is not supported, and nested tables, VARRAY of VARRAY and multi-dimensional arrays are all listed as unconvertible in the AWS action code index. The quieter problem is NUMBER, which converts without complaint. NUMBER without a declared precision holds anything, and a converter that maps it to an integer type based on the values it sampled will drop the cents.
How much does an Oracle to PostgreSQL migration cost?
The tooling is often free and the labor never is. Ora2Pg costs nothing, AWS Schema Conversion carries no license charge, and the replication service bills by the hour of instance time. What you pay for is the engineer time spent rewriting procedural code and the parallel-run period where both databases are live. Oracle licenses by Processor or Named User Plus, and the saving on that renewal is what usually funds the project.
Can you migrate Oracle to PostgreSQL with zero downtime?
With change data capture, yes, down to a cutover measured in seconds. Take a consistent snapshot, load it into PostgreSQL, then stream the redo changes until the target has caught up. AWS Database Migration Service requires the source to run in ARCHIVELOG mode with supplemental logging enabled at the database level and on each replicated table. Skip that setup and you get a full load with no changes following it.
Should I migrate Oracle to PostgreSQL or to Aurora PostgreSQL?
Aurora PostgreSQL if you are already in AWS and want the storage and failover handled for you, plain PostgreSQL if you want portability and the ability to run anywhere. The conversion work is nearly identical because Aurora PostgreSQL is PostgreSQL compatible, and AWS publishes its Oracle conversion playbook against Aurora specifically. Decide on operations and lock-in, not on how the schema converts.
What goes wrong in an Oracle to PostgreSQL migration?
The defaults that produce a schema which deploys cleanly and behaves differently. AWS DMS Schema Conversion converts materialized views to plain tables by default, so they stop refreshing. It starts converted sequences at their initial value by default rather than the last value used on the source, which collides with existing primary keys the first time an application inserts. Neither raises an error.

For the wider set of engines and the people cost that dominates every migration program, read what a data migration really costs. For the difference between moving data once and moving it continuously, see ETL vs ELT.

Migrate off Oracle once, then keep PostgreSQL in agreement with everything else

Map the fields once, run the backfill, then let the same mapping run incrementally with retries, alerts and per-record logs. From $49 a month, not metered by rows.

Try the live demo

No credit card required.