// Oracle to PostgreSQL migration
Oracle to PostgreSQL migration, and support for the database you land on
Oracle to PostgreSQL migration with OSSeva runs in four phases (assessment, schema and PL/SQL conversion, a dual run, then cutover), and the PostgreSQL cluster you land on moves straight into 24/7 support on your own servers, VMs, Kubernetes or cloud account. How long each phase takes depends on your schema size, how much PL/SQL you have, how many applications connect and the downtime window you can accept, so the assessment sets the dates. OSSeva does not support Oracle Database itself. A 15-minute discovery call starts the written assessment.
- The four phases
- Assessment, schema and PL/SQL conversion, dual run, cutover; then support
- Tools
- Ora2Pg for assessment, schema and data; orafce for Oracle-compatible functions and packages. Both are open source, so you keep them
- Oracle dates (endoflife.date)
- 19c: Premier Support to 31 Dec 2029, Extended to 31 Dec 2032. 21c: ends 31 Jul 2027, no Extended Support listed
- What sets the timeline
- Schema size, PL/SQL volume, number of applications and the downtime window you can accept
- Patch window
- Critical CVEs (CVSS 9.0 or higher) within 48 hours, High within 7 days
- Support hours
- Assure includes 24/7 reactive support; Operate adds managed operations and a 15-minute P1 response
Dates checked on endoflife.date on 20 October 2026. Tool behaviour from the Ora2Pg README, the orafce README, the AWS DMS Schema Conversion user guide and the PostgreSQL 18 documentation, all fetched on 20 October 2026.
Trusted globally by enterprises
Why teams leave Oracle Database
Three triggers start most Oracle exits. Whether a move pays for your estate depends on your own licences, hardware and staffing, so this page states no savings figure; the database support cost calculator works from the numbers you enter.
A support date forces a decision
Oracle 19c Premier Support ends on 31 December 2029 and Extended Support on 31 December 2032, and 21c ends on 31 July 2027 with no Extended Support listed (endoflife.date, checked 20 October 2026). A database that has to move to 26ai, or off Oracle, by those dates can be assessed against PostgreSQL first.
The licence and the audit sit in every renewal
Renewals and licence audits are when teams ask whether each database still needs Oracle. PostgreSQL is released under the PostgreSQL License, a liberal open source licence with no per-core fee, so the question becomes what the migration takes, and that is set by your PL/SQL and your applications.
The application can run wherever you choose
PostgreSQL runs on your own servers, VMs, Kubernetes or any cloud account, and the same engine can serve the rest of an open source stack. That removes the dependency on one vendor's terms but adds the work of running PostgreSQL, which is why support after cutover is part of the offer.
The dates that matter
2027-07-31
Oracle 21c Premier Support ends. No Extended Support is listed for 21c.
2029-11-08
PostgreSQL 17 reaches community end of life.
2029-12-31
Oracle 19c Premier Support ends.
2030-11-14
PostgreSQL 18 reaches community end of life.
2031-12-31
Oracle 26ai (endoflife.date lists it as release 23) Premier Support ends.
2032-12-31
Oracle 19c Extended Support ends.
The four phases of an Oracle to PostgreSQL migration
1. Assessment
An inventory of schemas, PL/SQL objects, data volumes, and the applications and jobs that connect. Ora2Pg's migration assessment report gives a first read on effort per object, and we add the application-side review it cannot see. You get a written plan with a verdict per database (migrate, defer or stay on Oracle) and a target PostgreSQL version.
2. Schema, PL/SQL and data conversion
Tables, indexes, constraints, sequences and views converted with Ora2Pg, PL/SQL converted to PL/pgSQL and then reviewed by hand, and orafce installed only where it saves application changes, with every use listed. Data loads are rehearsed table by table, with row counts and checksums compared on both sides.
3. Dual run
The converted application runs against PostgreSQL alongside Oracle. Query results, batch output and performance are compared, and differences are fixed before any user is moved.
4. Cutover
A written runbook with a final sync, go and no-go checks and a tested rollback to Oracle, run with your team in the change window. The cluster moves into support the same day.
What converts automatically and what does not
Ora2Pg does the mechanical work and says plainly that there is still manual work to do: the PL/SQL it generates for functions, procedures, packages and triggers has to be reviewed. This is the Oracle to PostgreSQL compatibility checklist the assessment starts from, with the conversion approach for each construct.
It lists risk areas, not a promise that each one occurs in your estate. The assessment finds which do, and marks every use as converting automatically, emulated with orafce, or needing a code change.
Oracle to PostgreSQL compatibility checklist
| Oracle construct | Automatic conversion | Conversion approach |
|---|---|---|
| Tables, indexes, constraints, sequences, views, grants | Yes | Exported by Ora2Pg, including range and list partitions. Review type mappings and partition keys, then load into a rehearsal database. |
| Character and LOB types: VARCHAR2, NVARCHAR2, CLOB, NCLOB, BLOB, LONG | Yes, by default mapping | Ora2Pg maps them to varchar, text and bytea by default, and its DATA_TYPE directive overrides the mapping per column. |
| NUMBER | Partly | The PG_NUMERIC_TYPE and PG_INTEGER_TYPE directives choose between numeric(p,s), integer types and the approximate real and float types. Ora2Pg's README says to keep numeric(p,s) for monetary columns because the approximate types round, and that numeric is slower. Decide per column. |
| DATE | Yes, with a decision | An Oracle DATE holds a time of day. Ora2Pg maps it to timestamp(0) by default, and orafce adds an Oracle-compatible date type and date functions where application code relies on them. |
| PL/SQL functions, procedures and triggers | Partly | Ora2Pg does basic automatic conversion to PL/pgSQL, and its README says the generated code has to be reviewed. Every object is converted, reviewed by hand and tested. Procedures need PostgreSQL 11 or later. |
| Packages and package variables | Partly | PostgreSQL has no packages. Ora2Pg exports each package as a schema of functions by default. The PostgreSQL manual says there are no package-level variables and suggests temporary tables for per-session state, so each package is reviewed for state and initialisation code. |
| Autonomous transactions | Yes, with a wrapper | Ora2Pg translates them into wrapper functions that use dblink or the pg_background extension. Test the wrapper under load, or move the logging out of the transaction. |
| COMMIT and ROLLBACK inside stored code | No | In PostgreSQL only procedures run with CALL, and DO blocks, can end a transaction; functions cannot. Loops that commit every N rows become procedures, or the batch loop moves into the application. |
| Exception blocks and SAVEPOINT | Review | A caught exception in PL/pgSQL rolls back everything since the block's BEGIN. Code that used SAVEPOINT and ROLLBACK TO in that style gets simpler; other uses need redesign. |
| Empty string and NULL | Partly | Oracle treats a zero-length character value as null and PostgreSQL does not. Ora2Pg's NULL_EQUAL_EMPTY directive rewrites IS NULL tests with coalesce(), and every place data can be empty still needs a test. |
| NVL, DECODE, DUAL, SYSDATE, LISTAGG | Yes, with orafce | orafce implements nvl, nvl2, decode, a dual table, sysdate and listagg. Calls it does not cover are rewritten, in application SQL as well as in database code. |
| Supplied packages: DBMS_OUTPUT, UTL_FILE, DBMS_PIPE, DBMS_ALERT, DBMS_RANDOM, DBMS_UTILITY | Partly, with orafce | orafce emulates these. Its README does not list DBMS_SCHEDULER, DBMS_JOB, DBMS_LOB, DBMS_CRYPTO or UTL_HTTP, so those become pg_cron or an external scheduler, native bytea handling, pgcrypto and application code. |
| CONNECT BY, ROWNUM, ROWID, (+) outer joins | Review | Rewrite as WITH RECURSIVE, LIMIT or row_number(), and ANSI joins. Ora2Pg's README says its default ROWID conversion fails on import and suggests bigserial, text or uuid. The assessment lists every query that uses them. |
| Synonyms and database links | Yes | Ora2Pg exports synonyms as views and database links as an Oracle foreign data wrapper server, which lets PostgreSQL query Oracle systems that stay behind. Links between databases that both move are removed. |
| Materialized view refresh | Partly | Ora2Pg exports materialized views as snapshots, because PostgreSQL only supports full refresh. Fast or incremental refresh becomes a scheduled full refresh, or a table kept current by triggers or jobs. |
| Optimizer hints and execution plans | No | Hints do not carry over; the PostgreSQL community says it is not interested in implementing hints the way other databases do. Plans differ, so a query that is fast on Oracle can be slow on PostgreSQL. Plans are reviewed during the dual run, and indexes and statistics tuned. |
| Advanced Queuing, Oracle Text, Spatial | No | Rebuilt on other features: a queue table or a message broker, PostgreSQL full-text search, PostGIS. Each is application work. |
| RAC and shared-storage clustering | No | PostgreSQL has no active-active shared-storage cluster; its documentation describes shared-disk failover, where one server at a time uses the disk array. Availability is redesigned around streaming replication with Patroni or repmgr. |
Sources fetched 20 October 2026: Ora2Pg README, orafce README, PostgreSQL 18 documentation (Porting from Oracle PL/SQL, transaction management, WITH queries, CREATE TABLE, high availability, pgcrypto), the pg_cron README, the PostgreSQL wiki page on optimizer hints and the Oracle Database 19c SQL Language Reference (Nulls).
Support after cutover
The new cluster moves into OSSeva support on the day of cutover, wherever it runs: your servers, VMs, Kubernetes or cloud account. The team that moved your data is the team that answers the pager, and Assure includes 24/7 reactive support. The tier decides how much of the running of the cluster OSSeva takes on.
Support tiers for the PostgreSQL cluster you land on
| Tier | What it adds | Response and patch terms |
|---|---|---|
| Patch | Signed PostgreSQL builds with backported security fixes once your major version passes community end of life (17 on 8 November 2029, 18 on 14 November 2030). | Critical CVEs (CVSS 9.0 or higher) patched within 48 hours, High within 7 days. |
| Assure | Everything in Patch, plus major-version migration planning, a performance and vacuum configuration audit, a compliance attestation package and 24/7 reactive support. | 24/7 reactive support. |
| Operate | Everything in Assure, plus managed operations: replication and failover monitoring, Patroni, repmgr and quorum monitoring, vacuum and analyze tuning, point-in-time recovery testing and quarterly capacity reviews. | 15-minute P1 incident response. |
Tier contents from the OSSeva PostgreSQL technology page. Support is priced per cluster; the discovery call gives the quote. PostgreSQL end-of-life dates from endoflife.date, checked 20 October 2026.
What does the Oracle to PostgreSQL assessment deliver?
The assessment is a written package, not a call. It starts from Ora2Pg's migration assessment report, which scans the Oracle database, and adds the application-side review the tool cannot see.
Assessment deliverables
| Deliverable | What it tells you |
|---|---|
| Object and code inventory | Schemas, tables, PL/SQL packages, procedures, functions, triggers, views, jobs and database links, with the code ranked by how much hand rewriting it needs. |
| Oracle-feature usage map | Every place database code and application SQL use an Oracle-only feature, each marked as converting automatically, emulated with orafce, or needing a code change. |
| Data profile and load plan | Table sizes, LOB columns, character set and type mappings, and how the load will be rehearsed and the final sync done. |
| Application and job connection map | Drivers, ORMs, batch jobs, reports and schedulers that connect to Oracle, each with a tested path to PostgreSQL. |
| Target design | The PostgreSQL version, extensions, high availability and backup design for where the cluster will run: your servers, VMs, Kubernetes or cloud account. |
| Risk register and fit verdict | The items most likely to stall the programme, and a plain answer for each database on whether to migrate it, defer it or leave it on Oracle. |
| Migration plan | The order of databases, the dual-run and cutover approach with a rollback, and who does what. Dates come out of the assessment, not before it. |
Can PostgreSQL replace Oracle Database?
For most OLTP applications you control, yes, and it is the usual way to replace Oracle Database. PostgreSQL is not a drop-in swap for every workload. It has no RAC-style shared-storage clustering, so designs that depend on RAC get a new availability design built on streaming replication with Patroni or repmgr. Applications that lean on Oracle-only engines, or that a vendor certifies only on Oracle, may be better left where they are.
The assessment answers this database by database. A verdict of defer or stay on Oracle is a normal result, and it is better to hear it before conversion starts than after.
Who does the work, and what is in writing?
The assessment ends in a written scope: what OSSeva converts and tests, what your team changes in the application, and who delivers each part. We do not state a duration in advance. It depends on how much PL/SQL there is, how large the schemas and data are, how many applications and jobs connect, and the downtime window you can accept, and the assessment is what turns those into a plan with dates.
Does OSSeva support Oracle Database itself?
No. This is a migration-out service. We assess your Oracle estate, convert it, move the data and then support the PostgreSQL you land on. We do not patch, tune or provide support for Oracle Database, and we do not advise on Oracle licensing. For the Oracle systems you keep, Oracle or a third-party Oracle support provider is the right partner.
How do the ways of replacing Oracle Database compare?
| Option | What you get | Trade-off |
|---|---|---|
| Stay on Oracle | No migration risk and no code changes | The licence and support contract stay, and so does the renewal conversation. |
| Managed PostgreSQL in a public cloud | A hosted target. AWS DMS Schema Conversion handles Oracle to Aurora or RDS for PostgreSQL, builds on the AWS Schema Conversion Tool engine and converts the schema, not the data | The database stays on that provider's service, versions and support calendar. |
| Do it yourself with open-source tools | Full control, using Ora2Pg, orafce and your own team | Your team carries the PL/SQL rewrite, the cutover and the PostgreSQL operations afterwards. |
| A migration specialist or systems integrator | Delivery capacity for large programmes | Scope often ends at cutover, so ask who runs and patches the PostgreSQL cluster afterwards. |
| OSSeva migration and support | One team from assessment through cutover, then PostgreSQL support on your infrastructure | A services engagement followed by a subscription, priced per cluster. Scope and delivery are confirmed in writing at the assessment. |
Tool behaviour from the Ora2Pg README, the orafce README, the AWS DMS Schema Conversion user guide and the PostgreSQL 18 documentation, fetched on 20 October 2026. Oracle and PostgreSQL dates from endoflife.date, checked on 20 October 2026. OSSeva coverage from the OSSeva PostgreSQL technology page. Savings depend on your own estate; the calculator uses your inputs and no assumed figures.
How do I migrate data from Oracle to PostgreSQL?
Rehearse the load table by table, for example with Ora2Pg's COPY or INSERT export, compare row counts and checksums on both sides, and do the final sync in the cutover window. AWS DMS Schema Conversion converts the schema only; moving the data is a separate AWS DMS feature. The data is the mechanical part of the project. The pace is set by the PL/SQL and the applications.
Why are people moving away from Oracle?
Three triggers recur: a support date that forces a decision (19c Premier Support ends on 31 December 2029), licence renewals and audits, and the wish to run the same applications on infrastructure of their choice. Whether the move pays depends on your own licences, hardware and staffing, which is why we give no figure and link a calculator that uses your inputs.
Why is Postgres better than Oracle?
Better depends on the workload. PostgreSQL has an open source licence with no per-core fee, runs on any infrastructure and has a large extension ecosystem. Oracle has RAC, Oracle-only engines and vendor-certified applications. For OLTP applications you control, PostgreSQL is a common replacement; where an application needs an Oracle-only feature, staying may be the better choice.
Can I get Oracle to PostgreSQL migration with 24/7 support after cutover?
Yes. The cluster moves into OSSeva support on the day of cutover. Assure includes 24/7 reactive support, Patch covers backported security fixes when your PostgreSQL major version passes community end of life (Critical CVEs within 48 hours, High within 7 days), and Operate adds managed operations and a 15-minute P1 response. Support is priced per cluster.
What decides how long an Oracle to PostgreSQL migration takes?
Schema size, the volume of PL/SQL and how much of it sits in packages, the Oracle-only features the application SQL uses, the number of applications and jobs that connect, and the downtime window you can accept. We do not quote a duration in advance; the assessment turns those inputs into an ordered plan, and the plan carries the dates.
When does Oracle 19c support end?
Premier Support ends on 31 December 2029 and Extended Support on 31 December 2032 (endoflife.date, checked 20 October 2026). After that 19c has Sustaining Support, with no new patches. Our post on Oracle 19c end of life sets out what each stage covers and the upgrade-to-26ai route.
Which tools do you use for Oracle to PostgreSQL migration?
Ora2Pg for assessment, schema conversion, basic PL/SQL to PL/pgSQL conversion, data export and validation, and the orafce extension where Oracle-compatible functions and packages save application changes. Both are open source, so you keep using them after we leave. On AWS, DMS Schema Conversion is another option when the target is Aurora or RDS for PostgreSQL.
How do you migrate Oracle to PostgreSQL using Ora2Pg?
Ora2Pg connects to the Oracle database, scans it and writes SQL scripts for the structure and the data that you load into PostgreSQL. In practice you run its assessment report first, export and review the schema, convert PL/SQL to PL/pgSQL and review the result by hand, then rehearse the data load before the final one.
What are the common challenges in Oracle to PostgreSQL migration?
PL/SQL packages and triggers that need hand rewriting, Oracle built-in functions and date handling in application SQL, differences in transaction and NULL behaviour, execution plans that change on the new optimizer, and the lack of a team to run PostgreSQL once the move is done.
Can PostgreSQL replace Oracle Database?
For most OLTP applications you control, yes. Where an application depends on Oracle-only features, on RAC-style shared-storage clustering, or a vendor certifies only Oracle, staying may be the better choice, and the assessment says so database by database.
What do you deliver in the assessment?
A written package: an object and code inventory, an Oracle-feature usage map, a data profile and load plan, an application and job connection map, a target design, a risk register with a verdict for each database, and a migration plan. It starts from Ora2Pg's migration assessment report.
How much will we save by leaving Oracle?
That depends on your licences, hardware and staffing, so we do not quote a figure. The database support cost calculator lets you enter your own numbers and compare.
Does OSSeva provide Oracle Database support?
No. This is a migration-out service. OSSeva supports PostgreSQL and the open-source data and messaging stack around it. We help you leave Oracle and support the PostgreSQL you land on, and we do not patch, tune or support Oracle Database itself.
Who is this for?
Teams with Oracle databases behind applications they own or can change, a renewal, audit or support date that gives them a reason to move, and a plan to run PostgreSQL on their own servers, VMs, Kubernetes or cloud account.
Get a quote
Plan your Oracle to PostgreSQL migration with the team that supports what comes after.
Book a 15-minute discovery call. The written assessment follows, and support is priced per cluster.
Prefer to talk or read more first?