An Oracle to PostgreSQL migration replaces a recurring per-processor licence and 22% support bill with a one-time conversion project and no licence at all. A fully-optioned Oracle Enterprise Edition estate lists near $122,000 per processor (Oracle Technology Price List, April 16 2026); PostgreSQL costs nothing to licence, so independent case studies show 70–90% TCO reductions. The catch is the conversion: schema moves almost automatically, but PL/SQL code converts only 50–70% automatically — budget the manual rewrite, and migrate the simple, high-cost workloads first.
Oracle to PostgreSQL migration is a total-cost-of-ownership decision, not a technology preference. The right model compares the full five-year Oracle cost — Enterprise Edition licences, the 22% support line that never stops, and every separately-priced option — against the one-time cost of re-platforming to PostgreSQL plus its ongoing infrastructure and administration. Every pricing and policy figure in this paper carries a source and a date, and every benchmark is labelled.
Key takeaways
- Oracle Database Enterprise Edition lists at $47,500 per processor, and a fully-optioned configuration with RAC, Partitioning, Diagnostics, Tuning, and more lists near $122,000 per processor (Oracle Technology Price List, April 16 2026) — the number a migration eliminates.
- Oracle support runs 22% of net licence value every year, with a typical ~8% renewal uplift, so a single EE processor carries about $10,450 in annual support before any options are added.
- PostgreSQL has no licence and no support tax — independent case studies report 70–90% database TCO reductions, and EnterpriseDB cites up to 80% TCO savings and up to 95% fewer application rewrites on Oracle-to-PostgreSQL moves (EnterpriseDB, 2026).
- Schema converts almost automatically; PL/SQL does not — tools such as AWS SCT and ora2pg convert table DDL at 90–95% but stored procedures at only 50–70% automatically (AWS Database Migration Guide, 2026), so the project cost lives in the procedural code.
- Across 600+ Oracle engagements, an Oracle-to-PostgreSQL conversion project typically costs 15–30% of one year of Oracle support and pays back inside the first year after cutover (Oracle Licensing Experts engagement data, 2026).
Recommendations by role
A database migration is decided by IT, paid for by finance, governed by procurement, and de-risked by the team that knows the code. Here is what each owner does to build a defensible TCO case and bank the saving.
CIO / Head of Infrastructure Strategy
- Inventory every Oracle database by edition, option, processor count, and annual support — you cannot model a saving you have not counted.
- Score each workload on PL/SQL complexity versus annual Oracle cost, then migrate the simple, high-cost databases first.
- Treat a partial migration as permanent negotiating power: a credible exit resets Oracle's discount on everything that stays.
CFO / Finance Cost
- Model the full five-year Oracle TCO — licence, 22% support, options, and renewal uplift — not just this year's invoice.
- Budget the conversion as a one-time capital project and set the payback against the recurring support line it removes.
- Hold the avoided support as a hard saving each year after cutover, and redirect it rather than letting it refill with new Oracle spend.
SAM / ITAM Manager Control
- Verify which options and packs are actually in use before counting their saving — deployed-but-idle options inflate both the bill and the case.
- Right-size the Oracle estate first: dropping unused options and over-licensed processors cuts cost on day one, before any migration.
- Document the migration so the retired Oracle licences are formally terminated and stop accruing support.
Head of Applications / Lead DBA Delivery
- Run AWS SCT or ora2pg early to get an automated conversion rate per object type and quantify the manual PL/SQL rewrite.
- Validate data-type mappings — an unchecked Oracle NUMBER-to-NUMERIC mapping introduces implicit casts that hurt performance.
- Plan parallel running and semantic testing for stored procedures; the procedural layer, not the data, is where projects overrun.
The Oracle to PostgreSQL TCO framework: seven questions that decide your business case
How much does Oracle Database Enterprise Edition actually cost per year?
Enterprise Edition (EE) is Oracle's full-feature database, listed at $47,500 per processor on the 2026 Technology Price List, but that headline is only the entry fee. Annual support adds 22% of net licence value every year — roughly $10,450 per processor — and never stops, with a typical ~8% uplift at renewal (Oracle Technology Price List, April 16 2026). A processor is physical cores multiplied by the Core Factor, so on common x86 hardware with a 0.5 factor, two cores equal one licence. The real annual cost is the support line, compounding, for as long as you stay.
If your renewal quote shows only licence and support, ask what options are attached. Partitioning, Diagnostics Pack, and Tuning Pack are billed separately per processor — an estate priced at "$47,500 EE" can be carrying two to three times that once the options stack is counted.
What does a realistic Oracle-to-PostgreSQL TCO model include?
Total cost of ownership (TCO) is the full multi-year cost of running the database, and a credible model puts both sides on the same five-year basis. On the Oracle side: EE licences, the 22% support line for all five years, every separately-licensed option, the renewal uplift, and the DBA effort to stay compliant. On the PostgreSQL side: zero licence, the one-time conversion project, plus ongoing infrastructure, administration, and any commercial-distribution support you choose. The honest comparison is recurring-and-compounding versus one-time-then-flat.
Model in five-year cumulative terms, not year one. A migration looks expensive in the first twelve months because the conversion lands up front; by year three the avoided Oracle support has paid it back several times over, and years four and five are almost pure saving.
PostgreSQL does not lower the Oracle bill — it removes it. The licence line goes to zero, the 22% support line goes to zero, and the option stack goes with it.
How much can you really save by migrating from Oracle to PostgreSQL?
The saving is the entire Oracle licence-and-support stack for every workload you move, because PostgreSQL has no per-processor licence and no 22% tax. Independent case studies consistently report 70–90% reductions in database TCO once licences, support, options, and specialised staffing are counted, and EnterpriseDB cites up to 80% TCO savings and up to 95% fewer application rewrites on Oracle-to-PostgreSQL migrations (EnterpriseDB, 2026). On a fully-optioned EE estate listing near $122,000 per processor (Oracle Technology Price List, April 16 2026), the avoided cost runs to six or seven figures a year — the larger and more heavily-optioned the estate, the larger the prize.
Across 600+ Oracle engagements, fully-optioned Enterprise Edition estates run 2.5–3× their base licence cost once Partitioning, Diagnostics, Tuning, and RAC are stacked on — and 30–60% of those options are deployed but barely used (Oracle Licensing Experts engagement data, 2026). Idle options are the single largest avoidable line in most Oracle bills.
What does the migration itself cost — and how do you budget the conversion?
Budget the migration as a one-time project whose cost is driven by code, not data volume. Table and schema DDL convert at 90–95% automatically, simple queries at 85–90%, but PL/SQL stored procedures convert only 50–70% automatically with tools such as AWS SCT and ora2pg (AWS Database Migration Guide, 2026). The remainder is manual rewrite into PL/pgSQL, plus semantic testing and performance re-tuning. In our engagements that whole project typically costs 15–30% of a single year of Oracle support and is recovered well inside the first year after cutover (OLE benchmark, 2026).
"Confirm in writing the termination process and effective date for the licences we are retiring, and that support will cease accruing from that date." Until retired licences are formally terminated, Oracle keeps billing support on databases you no longer run.
Which Oracle workloads are easy to move to PostgreSQL, and which are not?
Ease of migration tracks the procedural code, not the schema. Reporting databases, data marts, departmental applications, and anything built on plain tables and standard SQL move quickly. The hard cases are estates with thousands of PL/SQL packages, autonomous transactions, tightly-coupled application SQL, and proprietary Oracle constructs — these need rewriting and re-tuning before they will perform. The strategic move is to sequence by economics: migrate the simple, high-cost databases first to bank the saving while the complex, lower-cost ones are re-engineered or kept on Oracle and right-sized.
Moving even one tier of databases off Oracle changes every future renewal. Once Oracle sees a working PostgreSQL estate, the exit is proven rather than threatened — and a proven exit is the most effective discount lever you have on the workloads that remain.
How do PostgreSQL support and options compare to Oracle's 22% line?
The capabilities Oracle charges for separately are largely native to PostgreSQL or available without a per-processor tax. Partitioning is built into core PostgreSQL at no charge, where Oracle Partitioning lists at $11,500 per processor; high availability is handled by streaming replication, Patroni, or a commercial distribution rather than a paid RAC option; and compression and diagnostics are native or open-source. Where you want a support contract, commercial PostgreSQL distributions offer it for a flat subscription that is a fraction of Oracle's 22% — and unlike Oracle support, it is not a percentage of an ever-growing licence base.
In our client base, a typical Oracle-to-PostgreSQL migration removes 70–85% of annual database licence and support cost, and the replacement — infrastructure plus optional commercial support — lands at 15–30% of the former Oracle run-rate (OLE benchmark, 2026).
How do you sequence a migration so it de-risks your next Oracle audit and renewal?
Sequence the migration so each step both saves money and strengthens your position. Start by right-sizing the Oracle estate — drop unused options, reclaim over-licensed processors — which cuts cost before any code is touched and removes the soft compliance exposure auditors exploit. Move the simple, high-cost workloads next to prove the model and bank the saving. For databases too complex to move quickly, consider third-party support at roughly half Oracle's fee to cut cost while they are re-engineered. By renewal, you negotiate from a real, partly-migrated estate rather than a slide.
"Customer may reduce licensed quantities and terminate support for any program upon written notice, with support fees for terminated programs ceasing at the end of the then-current support period and not carried forward into, or repriced against, the remaining supported programs."
Which workloads should you migrate first?
Migrate first
Best ROI in the estate. Schema and SQL convert almost automatically, and the avoided EE-plus-options bill is large. These workloads fund the rest of the programme — move them in the first wave.
Phased re-engineering
Worth moving but not cheaply. Rewrite the procedural layer in stages, run parallel, and cut over by module. Use third-party support to cut Oracle cost while the work is done.
Migrate opportunistically
Easy but low-value on its own. Move these alongside the first wave to consolidate onto PostgreSQL and retire the Oracle footprint, not as a standalone business case.
Stay and right-size
Lowest priority to move. Keep on Oracle for now, strip unused options, consider third-party support, and revisit once tooling or a re-platform of the application makes conversion cheaper.
Sequence by economics, not by ease alone: the top-left quadrant pays for the programme, and a proven first wave resets your negotiating position on everything that stays.
Strengths and cautions of each database path
| Path | Strength | Caution |
|---|---|---|
| Stay on Oracle, right-size | No project risk; cuts cost fast by dropping idle options and over-licensed processors | The 22% support line and renewal uplift continue; lock-in and audit exposure remain |
| Migrate to PostgreSQL (re-platform) | Removes the licence and support stack entirely; 70–90% TCO reduction on moved workloads | One-time conversion cost; PL/SQL rewrite and testing must be funded and planned |
| Hybrid — move tier-2, keep tier-1 | Banks saving on simple workloads while complex ones stay; creates real negotiating power | Two engines to run and staff; needs a clear sequencing and retirement plan |
| Third-party support on Oracle | Roughly half Oracle's fee; bridges cost while complex databases are re-engineered | Forgoes Oracle updates and new releases; best as a transition, not a permanent end-state |
Acronyms and key terms
- Total Cost of Ownership (TCO)
- The full multi-year cost of running a database — licences, annual support, options and packs, infrastructure, and administration — the correct basis for an Oracle-versus-PostgreSQL comparison.
- Enterprise Edition (EE)
- Oracle's full-feature database edition, licensed at $47,500 per processor on the 2026 Technology Price List, before any options or packs are added.
- Processor Metric
- Oracle's per-processor licensing unit, calculated as physical cores multiplied by the Core Factor; the basis for both the licence fee and the 22% support charge.
- Core Factor
- A multiplier from Oracle's Core Factor Table applied to physical cores to derive licensable processors; common x86 cores carry a 0.5 factor, so two cores equal one processor licence.
- Support (22%)
- Oracle's annual technical support charge, set at 22% of net licence value per year with a typical ~8% uplift on renewal; the recurring cost a migration eliminates.
- Options and Packs
- Separately-licensed Oracle add-ons such as Partitioning, Multitenant, Diagnostics Pack, and Tuning Pack, each priced per processor on top of the base database.
- PL/SQL
- Oracle's proprietary procedural language for stored procedures, packages, and triggers; the part of a migration that converts least automatically.
- PL/pgSQL
- PostgreSQL's procedural language, the conversion target for Oracle PL/SQL code during a migration.
- ora2pg
- An open-source tool that extracts an Oracle schema and generates PostgreSQL-compatible SQL, automating most table and view conversion but not complex packages.
- AWS SCT
- The AWS Schema Conversion Tool, which converts Oracle schema and code to PostgreSQL and reports the proportion of objects needing manual rework.
- Re-platform
- Moving a workload to a different database engine with code conversion and testing, as opposed to a like-for-like lift-and-shift; the correct frame for an Oracle-to-PostgreSQL move.
- Third-Party Support
- Independent maintenance for an Oracle database at roughly half Oracle's fee, used to cut cost on workloads that remain on Oracle during a phased migration.
Oracle to PostgreSQL migration FAQ
How much does it cost to migrate from Oracle to PostgreSQL?
Budget the migration as a one-time project, not a licence purchase. Schema and table DDL convert almost automatically, but PL/SQL stored procedures convert only 50–70% automatically with tools such as AWS SCT and ora2pg (AWS Database Migration Guide, 2026), so the cost is driven by manual code rewrite, testing, and parallel running. Across our engagements a conversion project typically costs 15–30% of a single year of Oracle support — and is recovered well inside the first year after cutover (Oracle Licensing Experts engagement data, 2026).
How much do you save by migrating from Oracle to PostgreSQL?
PostgreSQL has no per-processor licence and no 22% support line, so the saving is the entire Oracle licence-and-support stack for the workloads you move. Independent case studies report 70–90% reductions in database TCO, and EnterpriseDB cites up to 80% TCO savings and up to 95% fewer application rewrites (EnterpriseDB, 2026). On a fully-optioned Enterprise Edition estate listing near $122,000 per processor (Oracle Technology Price List, April 16 2026), the avoided cost runs to six or seven figures a year.
Is PostgreSQL a drop-in replacement for Oracle?
No. PostgreSQL is a mature, fully relational database, but Oracle and PostgreSQL diverge on procedural language, data-type behaviour, and proprietary features. Table structures and simple SQL move easily; PL/SQL packages, autonomous transactions, and performance-critical procedures need rewriting into PL/pgSQL and re-tuning (AWS Database Migration Guide, 2026). Treat it as a re-platform project with code conversion and testing, not a lift-and-shift — and the economics still favour the move for most estates.
How long does an Oracle to PostgreSQL migration take?
It depends on the volume and complexity of PL/SQL, not the data size. A simple, lightly-coded schema can move in weeks using automated tooling; a heavily-coded estate with thousands of stored procedures and tight application coupling runs several months including parallel running. Sequence by workload: move the simple, high-cost databases first to bank the licence savings while the complex ones are re-engineered.
Does PostgreSQL have an equivalent to Oracle RAC and Partitioning?
Partitioning is built into core PostgreSQL at no extra charge, where Oracle Partitioning lists at $11,500 per processor on top of the database (Oracle Technology Price List, April 16 2026). High availability is handled by streaming replication, Patroni, or commercial distributions rather than a paid RAC option. The capabilities you pay Oracle separately for — partitioning, compression, diagnostics — are either native to PostgreSQL or available through open-source and supported distributions.
Should I migrate to PostgreSQL or just renegotiate my Oracle contract?
Do both, in order. A migration is your strongest negotiating position because it is a credible exit, not a bluff — so model the PostgreSQL TCO first, then take it into the renewal. Many estates right-size and renegotiate Oracle for the workloads that are too complex to move, while migrating the simple, high-cost databases. The threat of departure plus a real partial migration routinely resets Oracle's discount on what remains.
What is the biggest hidden cost in an Oracle to PostgreSQL migration?
Stored-procedure and application-code conversion. Schema converts cleanly, but business logic embedded in PL/SQL packages, triggers, and tightly-coupled application SQL cannot be fully automated and is where projects overrun. Budget for manual rewrite, semantic testing, and performance re-tuning of the procedural layer, and validate data-type mappings — a blanket Oracle NUMBER-to-NUMERIC mapping introduces implicit casts that hurt performance if left unchecked (AWS Database Migration Guide, 2026).
Methodology & sources
The pricing, support, and option figures in this model are drawn from Oracle's published 2026 Technology Price List and conversion-rate data from AWS's migration documentation, combined with Oracle Licensing Experts engagement data across 600+ Oracle negotiations, audits, and database optimisation projects. Proprietary benchmarks are labelled "OLE engagement data, 2026" or "OLE benchmark, 2026" and reflect outcomes from buyer-side advisory work; they are directional ranges, not guarantees. Oracle revises its price list periodically and conversion rates vary by estate — always confirm the live figure for your region and run an automated assessment before committing a budget.
- Oracle Corporation, Oracle Technology Global Price List, April 16, 2026 — Enterprise Edition, options, and packs per-processor list pricing and 22% support basis.
- Oracle Corporation, Oracle Database Licensing Information User Manual, 2026 — editions, options, packs, and Processor/Named User Plus metrics.
- Amazon Web Services, Oracle to PostgreSQL Database Migration Guide, 2026 — AWS SCT and ora2pg schema and PL/SQL conversion rates and manual-rework guidance.
- EnterpriseDB, Cost Savings & ROI Moving from Oracle to PostgreSQL, 2026 — reported TCO savings, up-to-95% reduced application rewrites, and migration tooling benchmarks.
- Oracle Licensing Experts engagement data, 2026 — option utilisation, conversion-project cost ranges, and payback outcomes across 600+ engagements.
Download this model as a PDF
Take the full Oracle to PostgreSQL Migration TCO Model into your next budget cycle — the five-year cost comparison, the migration-first decision matrix, and the conversion-cost benchmarks in one printable brief. We also build a costed, workload-by-workload TCO model against your live Oracle estate on request.
Request the PDF & a TCO model →Keep reading
Free weekly Oracle briefing
Database TCO benchmarks, support-cost intelligence, and migration tactics — from former Oracle insiders.
Model your Oracle exit before your next renewal
Get an independent, buyer-side TCO model of your Oracle estate against PostgreSQL — the real five-year cost, the workloads to move first, the idle options to drop today, and the conversion budget to plan. We have advised on $1.8B of Oracle spend and cut costs an average of 38%.