TL;DR: Oracle licensing has become a serious financial burden.
A dual-socket server running Oracle Enterprise Edition can cost over €350,000 in base licenses alone, with 22% annual support fees that rise every year.
PostgreSQL is now the most widely used database among developers, with 55.6% adoption overall and 58.2% among professional developers in the 2025 Stack Overflow Developer Survey and proven enterprise maturity.
Companies that have made the switch report 70–80% reductions in database licensing costs.
This post explains what's driving the exodus and what it takes to migrate safely.
Your Oracle support renewal lands on your desk.
The number is higher than last year.
Again.
You push back.
Oracle says that's the price.
You sign, because you don't have a choice right now.
This scenario plays out across thousands of IT departments every year.
It's the primary reason companies are now seriously evaluating Oracle to PostgreSQL migration in numbers that would have been unthinkable five years ago.
After 20 years managing Oracle environments at companies including a major European bank running a 14,000-database Exadata estate and a leading Spanish bank running mission-critical Oracle RAC 12c and 19c, I've watched this shift happen firsthand.
The question my clients ask isn't “should we migrate?” anymore.
It's “when, and how do we do it without breaking anything?”
Here's what you need to know.
Table of Contents
Why Is Oracle Suddenly So Expensive?
Oracle Enterprise Edition costs around €43,000 per processor license, plus 22% annual support fees that compound every year.
Add-ons like RAC, Partitioning, and Diagnostics Pack push fully configured deployments to two or three times the base cost.
Oracle controls pricing through NDA-negotiated contracts — customers have no leverage on the final number.
A basic dual-socket Intel server with 16 cores runs to €350,000 in base EE licenses alone, before any add-on options.
Most companies running production Oracle estates are paying for several add-ons without realising it.
The Oracle Technology Price List is public, but the amounts companies actually pay are negotiated under NDA.
Oracle controls the entire pricing conversation.
That's by design.
Is PostgreSQL Really Ready for Enterprise Workloads?
Yes — and has been for several years.
PostgreSQL supports ACID transactions, partitioning, logical replication, full-text search, JSON, and parallel query.
According to the 2025 Stack Overflow Developer Survey, it has 55.6% overall developer adoption and 58.2% among professional developers — the most widely used database among developers for four consecutive years.
The PostgreSQL 17 release announcement states that high concurrency workloads may see up to 2x better write throughput due to improvements in WAL processing.
Thirty years of continuous development since the POSTGRES project at UC Berkeley.
A commercial ecosystem that now includes EDB, Percona, Crunchy Data, and Supabase, all providing enterprise support, HA tooling, and managed cloud services.
The technical gap with Oracle is real but manageable.
It's not the technology that causes migrations to fail.
What trips teams up is underestimating the complexity of PL/SQL conversion and application-level dependencies.
What Companies Are Actually Saving
The financial case is no longer theoretical.
Real numbers from published case studies:
- A global telecom migrated from Oracle to PostgreSQL and reduced database costs by 70%, while cutting deployment times in half.
- A company that migrated a 10TB Oracle database saw licensing spend drop by approximately 80% with no business disruption.
- One analysis found a 340% ROI over three years from a completed Oracle to PostgreSQL migration, factoring in migration costs, tooling, and the full elimination of Oracle license and support fees.
The 70–80% figure for licensing cost reduction comes up consistently across case studies.
The driver is simple: PostgreSQL is free.
You still pay for infrastructure, support contracts (if you want them), and the migration itself.
But the compounding 8–10% annual Oracle support increase stops.
Permanently.
What Are the Hidden Risks of an Oracle Audit?
Oracle audits on a 2–3 year cycle and routinely finds unlicensed options — Diagnostics Pack, Tuning Pack, Partitioning — enabled without anyone realising the licensing implications.
Each triggers retroactive fees.
Companies running Oracle on VMware face additional exposure: Oracle requires licensing for every physical host in a VMware cluster, regardless of actual usage.
Audit bills routinely run to six or seven figures.
According to Redress Compliance, Oracle's audit frequency has been increasing since 2024.
Outcomes are rarely minor.
The VMware exposure is particularly underappreciated: a small Oracle deployment on a large VMware farm can generate licensing exposure running into millions of euros.
Staying on Oracle carries its own financial risk.
The longer you stay, the more likely you are to face an audit bill that dwarfs the cost of migrating.
If you're not sure whether your Oracle environment is a good migration candidate, I offer a fixed-fee assessment that answers exactly that question — risk register, complexity scoring, and a realistic cost/benefit projection. See the assessment service →
Is the Migration Technically Difficult?
Oracle to PostgreSQL migration is technically complex but manageable.
The data movement is not the hard part.
The hard parts are PL/SQL to PL/pgSQL conversion, data type mapping, and application-layer dependencies.
Tools like ora2pg automate 60–80% of schema conversion — the remaining 20–40% requires hands-on review and rewriting.
Oracle uses data types (NUMBER, VARCHAR2, DATE, CLOB) that don't map directly to PostgreSQL equivalents.
PL/SQL packages, cursors, and exception handling need to be rewritten, not just converted.
Stored procedures that rely on Oracle-specific behaviour — implicit type coercion, the DUAL table, ROWNUM — need careful handling.
ora2pg handles the bulk of schema conversion automatically.
It does not handle the edge cases.
The code conversion is where you need someone who knows both sides deeply.
What a Safe Migration Actually Looks Like
A safe Oracle to PostgreSQL migration follows five phases:
Phase 1: Assessment
Inventory your schemas, stored procedures, custom objects, and application dependencies.
This is where you find the surprises.
A paid assessment — typically 3 days — gives you a fixed-price project quote and a realistic risk register before you commit to anything.
Phase 2: Schema and Code Conversion
Data type mapping, PL/SQL to PL/pgSQL conversion, sequences, partitioning, triggers, and views.
Tools like ora2pg automate 60–80% of this.
The remaining 20–40% requires hands-on rewriting.
Phase 3: Data Migration
Full initial load followed by continuous replication using CDC (Change Data Capture) to keep PostgreSQL in sync while Oracle stays live.
AWS DMS handles this well for most environments.
Phase 4: Testing
Functional validation row by row.
Performance comparison against Oracle baselines.
Application regression testing.
This phase takes longer than most teams expect.
Phase 5: Cutover
A planned maintenance window — as short as a few minutes with a zero-downtime strategy — where traffic switches from Oracle to PostgreSQL.
Oracle is kept running but frozen for a rollback window, typically two to four weeks.
If a critical issue surfaces on PostgreSQL, traffic can be switched back to Oracle — though any data written to PostgreSQL during that window would be lost, so the decision to roll back needs to happen quickly.
Timeline ranges from 3 weeks for a small database with minimal PL/SQL to 3 months for a medium-complexity environment.
Large, heavily customised Oracle estates require a custom scoping exercise before committing to a timeline.
In Summary
Oracle licensing costs are rising every year.
Audits are increasing in frequency and severity.
PostgreSQL has reached a level of enterprise maturity that makes it a credible replacement for most Oracle workloads.
The companies that have made the switch report 70–80% reductions in database licensing spend.
Three things to take away from this post:
- The financial case for migrating from Oracle to PostgreSQL is strong and gets stronger with every Oracle price increase.
- PostgreSQL is production-ready. The risk is in how you execute the migration, not in the technology itself.
- PL/SQL conversion and application dependencies are the hard parts. Data movement is not.
If you're evaluating an Oracle to PostgreSQL migration, the right first step is a scoping assessment.
Contact me at rootfan.com for a free 30-minute call to discuss your environment.
No sales pitch — just a technical conversation about whether migration makes sense for your situation.
Frequently Asked Questions
How much does an Oracle to PostgreSQL migration cost?
It depends on schema count, PL/SQL complexity, and high availability requirements.
The first step is always a fixed-fee assessment that gives you a risk register and a project quote before you commit to anything.
See the full pricing breakdown on the services page at rootfan.com/services/.
How long does an Oracle to PostgreSQL migration take?
A small migration typically runs 3–4 weeks.
A medium-complexity migration runs 2–3 months.
The timeline depends primarily on the volume of PL/SQL code, the number of application dependencies, and the level of testing required before cutover.
A proper assessment gives you an accurate estimate before you commit.
Can PostgreSQL handle Oracle RAC-level availability?
PostgreSQL achieves high availability through etcd for cluster state and leader election, Patroni for automatic failover, and HAProxy or a virtual IP to route connections to the current primary.
This architecture provides solid HA for most workloads.
For extremely high-write workloads that rely on Oracle RAC's shared-disk model, the HA architecture needs careful evaluation during the assessment phase.
Will my PL/SQL packages work in PostgreSQL?
Not without conversion. PostgreSQL uses PL/pgSQL, which differs from PL/SQL on cursors, exception handling, packages, and Oracle-specific functions.
Tools like ora2pg handle the structural conversion.
The procedural logic — especially exception handling edge cases and implicit type coercion — requires manual review and rewriting.
What happens to Oracle performance levels after migrating to PostgreSQL?
Performance after migration depends heavily on query optimisation. Oracle-specific hints, ROWNUM usage, and implicit type handling don't translate directly.
After a proper PostgreSQL performance tuning pass, queries typically run at comparable or better performance than the Oracle original.
Gains are most visible in I/O-intensive workloads where PostgreSQL's MVCC model and flexible index options perform well.