An Oracle to PostgreSQL migration usually starts the same way: someone opens a renewal notice, a ULA true-up, or an audit letter, and the number on it is large enough to justify asking what it would actually cost to get off Oracle entirely. The honest answer depends on two things that have almost nothing to do with how big the database is — how many lines of PL/SQL it runs, and how tightly that code depends on Oracle-specific behavior.
This guide breaks the cost into its two real components: what staying on Oracle costs in stacked licensing, and what the migration itself costs in schema and procedural-code conversion, using Oracle's own published price list and the migration documentation AWS, Google Cloud, Microsoft, and EDB publish for their own tooling. It also covers the compatibility gaps that turn into unplanned labor hours, and the discovery work that has to happen before any number is worth trusting.
Prefer to skip the debugging and have an expert handle this? Book a 30-min diagnostic →
What 'Oracle to PostgreSQL Migration' Actually Includes
A genuine Oracle to PostgreSQL migration is a heterogeneous migration: moving between two structurally different database engines, not just relocating the same engine to new infrastructure. That distinction matters because it changes what has to be converted. It includes schema and data-type conversion — tables, constraints, indexes, sequences, views, and materialized views — plus procedural code conversion, turning PL/SQL packages, stored procedures, functions, and triggers into PL/pgSQL or an Oracle-compatible equivalent.
It includes the data migration itself, usually as continuous, change-data-capture-based replication with a defined cutover rather than a one-time dump, and any application-layer changes the target's different transaction model, connection model, or data-type semantics require. What it does not include, on its own, is a version upgrade within Oracle, a lift-and-shift of Oracle onto a cloud-hosted Oracle instance, or an application rewrite undertaken independently of the database change. All three get bundled into migration budgets in practice, but each is a distinct cost center with its own scope.
The Licensing Number That Undersells the Case
Oracle Database Enterprise Edition lists at $47,500 per processor in license fees, plus $10,450 per processor per year in support — a flat 22% of the license fee — per Oracle's own Technology Global Price List. That figure is the number every article cites, and it's also the least representative one, because it covers only the base engine. Real Application Clusters adds $23,000/processor plus $5,060/year.
Partitioning, Advanced Compression, and Active Data Guard each add $11,500/processor plus $2,530/year. Advanced Security adds $15,000/processor plus $3,300/year. The Diagnostics and Tuning Packs most DBAs actually use to run the thing add $7,500 and $5,000/processor, plus $1,650 and $1,100/year.
Stack a fairly ordinary configuration — partitioning, compression, a standby via Active Data Guard, and basic diagnostics and tuning tooling — and you've added $50,500/processor in license and $11,140/processor/year in support on top of the base numbers, before RAC is even in the picture. That's $100,000+/processor in license alone for features PostgreSQL includes in core at no additional cost: partitioning, compression, and streaming replication for a standby. This gap, not the $47,500 sticker price, is the number that actually explains the licensing side of the decision.
What the Migration Itself Costs: Code, Not Data
The licensing gap explains why a company wants to leave Oracle. It says nothing about what leaving costs, and that's the part most vendor content skips. Two independently published case studies point the same direction.
A financial services company with 250,000 lines of PL/SQL spent roughly $850,000 on code refactoring alone — 45% of its total migration budget, implying a total spend near $1.9 million — according to a case study DataPatrol published. The same source gives a general heuristic: application code refactoring typically runs 30-60% of total migration cost, at 40-80 hours per 1,000 lines of PL/SQL. A separate case study from Ispirer describes an 11-month migration covering 1,400+ tables, 400 packages, and 400,000+ lines of code, using automated conversion for the bulk of it and a final manual pass for dynamic SQL, hierarchical queries, functions with OUT parameters, and system objects the tooling couldn't fully resolve.
Both figures come from vendors with an interest in demonstrating complexity, so treat them as directional rather than audited benchmarks — but they converge on the same structural point AWS's own migration guidance backs independently: PL/SQL conversion, not data volume, is what drives cost. A 10 TB database with a clean schema and minimal PL/SQL is a cheaper migration than a 500 GB database running 400,000 lines of packages, a distinction flat cost-per-terabyte estimates miss entirely.
Two Conversion Paths: Native Compatibility vs. Translation
There are two structurally different ways to convert Oracle's procedural code, per EDB's own migration documentation. Native compatibility runs on EDB Postgres Advanced Server, a commercial PostgreSQL distribution that implements Oracle-compatible syntax and PL/SQL support directly, which minimizes how much code has to be rewritten. Translation uses automated tooling — AWS SCT, ora2pg, Microsoft's Azure conversion tool — to rewrite Oracle-specific objects into native PostgreSQL equivalents, and is the only option when the actual target is open-source PostgreSQL rather than EPAS.
EDB's own docs note most real migrations combine both: automated translation for the majority of objects, with EPAS-style compatibility or manual rework for what doesn't convert cleanly. EDB's own marketing claims migrations in under 20 days, up to 95% less application rewrite, and up to 80% lower TCO — those are EDB's own unaudited figures, not independently verified numbers. The choice trades a small ongoing commercial relationship for materially less PL/SQL rewrite.
Choosing pure open-source PostgreSQL trades the opposite way: more upfront conversion labor for zero ongoing vendor dependency. Teams that pick open-source PostgreSQL without budgeting for that added conversion effort are the ones who most often underestimate total cost.
Still Piecing This Together Yourself?
A senior engineer looks at your actual setup, not a generic checklist, and tells you exactly what's wrong and how to fix it.
Book a Diagnostic CallThe Conversion Tooling Landscape
Four platforms publish their own free or near-free conversion tooling, each tied to where you're ultimately hosting. AWS Schema Conversion Tool, paired with AWS DMS, connects directly to Oracle, reads PL/SQL, generates PL/pgSQL automatically, and produces an assessment report scoring conversion complexity before any code is touched — useful even outside an AWS migration, as a planning tool. Google Cloud's Database Migration Service handles both one-time and continuous CDC migration in a single managed service, with Gemini-assisted review of conversion issues, though it doesn't support Oracle Autonomous Database as a source and is limited to Oracle 11g through 21c at specific minor versions.
Microsoft's Azure schema-conversion tool is notably AI-agent-based rather than purely rule-based, with deep handling of hard cases — package constants become IMMUTABLE getter functions, CONNECT BY hierarchical queries convert to WITH RECURSIVE — but Azure Database Migration Service doesn't natively support Oracle as a source, so Microsoft's own docs point to ora2pg for the data-movement half. ora2pg itself is free, open-source, Perl-based, and cloud-agnostic: it connects to Oracle, scans the structure, and generates SQL for PostgreSQL 8.4 and later, covering tables, views, sequences, indexes, constraints, and predefined functions, triggers, and packages. Which tool fits depends more on your target cloud than on any feature comparison between them.
The Compatibility Gaps That Turn Into Labor Hours
Packages are the single largest structural gap: PostgreSQL has no direct equivalent. Per Microsoft's own conversion documentation, package constants convert to IMMUTABLE getter functions, package-level state variables become getter/setter pairs backed by a PostgreSQL session setting, VARRAYs and nested tables become array domains, string-keyed associative arrays become jsonb, and user-declared exceptions convert to functions returning a SQLSTATE value. The transaction model shifts at the routine level too — a PL/SQL routine using PRAGMA AUTONOMOUS_TRANSACTION stays a function with the autonomous work routed through dblink, while a routine with an explicit COMMIT or ROLLBACK converts to a PostgreSQL procedure instead, because only procedures can control transactions there.
A quieter but common source of silently wrong behavior: NO_DATA_FOUND and TOO_MANY_ROWS exceptions are disabled by default on a SELECT INTO in PL/pgSQL — the STRICT keyword has to be added back in to restore Oracle's original behavior. The riskiest gap is semantic, not syntactic: PostgreSQL's CREATE FUNCTION only confirms a routine's body parses, not that the tables or columns it references actually exist, so a broken routine deploys cleanly and fails the first time it runs. Azure's tooling addresses this by running every converted routine through the plpgsql_check extension in a scratch database before accepting it — but per Microsoft's own docs, that check is fail-open: if the extension isn't installed on the scratch server, the semantic validation silently doesn't run, with no warning surfaced in the report.
Why Discovery Comes Before Any Number You Can Trust
AWS's own migration guidance structures Oracle-to-PostgreSQL planning around seven sequential phases starting with discovery, and states directly that inadequate investigation is the single most common cause of delays, budget overruns, and post-cutover incidents — recommending six weeks for discovery alone, not as a padding figure but as a floor. Discovery's job is dependency mapping: finding hidden database links and undocumented APIs, establishing which applications are tightly coupled to the database and therefore have to cut over together versus which can migrate independently, and getting explicit, quantified success metrics agreed across business owners, application teams, DBAs, operations, and security — AWS's own example being something like 'claims batch processing takes 6 hours; target 3 hours or less,' not a vague goal to make it faster. This is why a prospect asking for a number before that assessment has happened is asking a question nobody can answer honestly yet.
Pricing a migration off database size in gigabytes, instead of off an object-level, PL/SQL-weighted complexity assessment, is the single most common way a migration estimate ends up wrong.
Get a Straight Answer, Not a Sales Pitch
Tell us what you're running into. We'll tell you directly what's causing it and what it takes to fix, before you sign anything.
Contact UsWhat Pushes Your Specific Number Up or Down
The clearest fit for a contained, well-scoped migration is a small number of Oracle databases, moderate PL/SQL complexity in the thousands to low tens of thousands of lines rather than the 250,000-to-400,000-line cases the published case studies describe, and a clear business trigger — a renewal, an audit notice, or a cloud modernization mandate — rather than a purely aspirational 'we should modernize' motivation with no forcing function behind it. Segments worth qualifying more carefully before committing to a scope: heavy Real Application Clusters or Exadata dependency, where the tooling gaps above are worse; very large package-count codebases with no existing automated test suite, where the semantic-validation gap becomes a genuine production-incident risk rather than a theoretical one; and organizations that want a fixed price before any discovery-equivalent assessment has happened, which AWS's own guidance argues against providing honestly. On the other side of the licensing motivation, Oracle's market position has been in structural decline for over a decade — it lost the #1 DBMS spot in 2019 and has sat third behind AWS and Microsoft since 2022, while PostgreSQL became the most popular database among developers by 2023, per Gartner data as reported by The Register and Stack Overflow's own developer survey.
That's market context, not a migration cost driver on its own, but it's useful for understanding why this decision keeps coming up.
A Realistic Way to Estimate Your Own Number
There's no independent public benchmark suite for migration cost the way there is for, say, database performance — the closest equivalent is the assessment tooling itself. Start with an AWS SCT-equivalent assessment, regardless of target platform, to get an object-level count and an automated-versus-manual conversion split before anyone quotes a number. Weight the manual-conversion object count by the 40-80 hours per 1,000 lines heuristic as a sanity check on labor, not as a firm quote.
Treat database size in gigabytes or terabytes as a data-movement-time input only, never as a cost driver, since the evidence above is explicit that code volume and package complexity are what actually move the number. From there, a migration typically follows the same sequence regardless of target: discovery and dependency mapping, an explicit decision between native compatibility and translation, automated conversion followed by manual resolution of the flagged objects, a semantic validation gate that actually runs and is confirmed to have run, CDC-based data migration for any system with an uptime requirement, a cutover window with a tested rollback path, and a post-cutover period for connection pooling and vacuum tuning — the operational differences that don't show up until the system is carrying real production load.
Related: Database Engineering
The $47,500-per-processor figure gets all the attention because it's the easiest number to find, but it's the wrong number to build a business case on in either direction. On the cost-of-staying side, the real figure is the stacked one — $100,000+ per processor once the features PostgreSQL includes for free are actually accounted for. On the cost-of-leaving side, the real driver isn't the database's size, it's how much PL/SQL it runs and how deeply that code depends on packages, hierarchical queries, and Oracle-specific transaction behavior.
Both numbers are knowable, but only after a discovery-equivalent assessment has scored the actual codebase rather than assumed a figure from the terabyte count. If a renewal notice, an audit letter, or a cloud modernization mandate has put this question in front of you, the right first step isn't a quote — it's the assessment that makes a quote honest.
Frequently Asked Questions
How much does an Oracle to PostgreSQL migration cost?
It depends far more on how much PL/SQL your database runs than on how large it is. Published case studies show code conversion alone running 30-60% of total migration budget, at roughly 40-80 hours per 1,000 lines of PL/SQL. A database with a clean schema and minimal procedural code migrates for a fraction of what a package-heavy codebase of the same size costs. The only way to get a defensible number is a discovery-phase assessment that scores your actual PL/SQL and package complexity before anyone quotes a figure.
Is PostgreSQL actually free compared to Oracle?
PostgreSQL itself carries no license fee, and partitioning, compression, and streaming replication for a standby are built into core PostgreSQL at no extra cost. Oracle Enterprise Edition lists at $47,500/processor plus 22% annual support, and a realistic production configuration with those same three capabilities plus basic DBA tooling adds another $50,500+/processor in license before a single support invoice arrives — $100,000+/processor in total. The license-fee difference is real; it just isn't the whole cost picture, since the migration itself has its own cost.
What's the biggest cost driver in an Oracle to PostgreSQL migration?
PL/SQL-to-PL/pgSQL conversion, not data movement. AWS's own migration guidance and two independently published vendor case studies converge on this: database size in gigabytes affects how long the data transfer takes, but the labor cost scales with lines of procedural code and package complexity. A 10 TB database with a simple schema is a cheaper migration than a 500 GB database running hundreds of thousands of lines of PL/SQL packages.
Should I choose EDB Postgres Advanced Server or open-source PostgreSQL?
It's a tradeoff, not a default. EDB Postgres Advanced Server implements Oracle-compatible syntax and PL/SQL support directly, which reduces how much code needs rewriting, in exchange for an ongoing commercial relationship with EDB. Open-source PostgreSQL requires more upfront conversion effort since every Oracle-specific object gets translated rather than natively supported, but carries no ongoing vendor dependency. Teams that choose open-source PostgreSQL without budgeting for that added conversion labor are the ones most likely to underestimate total cost.
How long does an Oracle to PostgreSQL migration take?
AWS's own guidance recommends six weeks for discovery alone, before any conversion work starts, because inadequate investigation is the most common cause of delays and post-cutover incidents. Beyond discovery, timeline scales with PL/SQL volume: a published case study covering 1,400+ tables, 400 packages, and 400,000+ lines of code took 11 months. Smaller, mid-market codebases in the thousands to low tens-of-thousands of lines run considerably shorter.
Can I get a fixed price for an Oracle to PostgreSQL migration before any assessment?
Not an honest one. AWS's own migration guidance sequences discovery before any commitment, specifically because database size doesn't predict cost — PL/SQL volume and package complexity do, and those are only knowable after an object-level assessment. A vendor willing to quote a fixed price before that assessment has happened is either padding the number heavily or guessing.
What compatibility issues drive up Oracle to PostgreSQL conversion cost the most?
Oracle packages, which have no direct PostgreSQL equivalent and require decomposing constants, session-scoped state, and nested table types into separate functions and session-setting-backed workarounds. Close behind: routines using PRAGMA AUTONOMOUS_TRANSACTION or explicit COMMIT/ROLLBACK, which change object type during conversion, and the fact that PostgreSQL's CREATE FUNCTION only validates that code parses, not that it's semantically correct — so every converted routine needs an explicit validation pass, not just a successful deployment, to catch silently broken code before production.
Who do I hire to do an Oracle to PostgreSQL migration?
Look for a team that treats discovery as a distinct phase before quoting a number, not one offering a fixed price off database size alone. DharmOps runs Oracle to PostgreSQL migrations as a Database Engineering engagement, starting with the same PL/SQL and package-complexity assessment this guide describes, before any migration scope is committed to.
How do I get a quote for an Oracle to PostgreSQL migration?
Not from database size alone — as this guide covers, PL/SQL volume and package complexity drive cost, not gigabytes. A Diagnostic Call is the starting point: it scopes your actual codebase against the tooling and conversion paths above before any number gets put in writing.
Can I migrate from Oracle to PostgreSQL without an outside consultant?
Small, low-PL/SQL databases are realistic to migrate in-house using ora2pg or AWS SCT directly. Once package count, autonomous transactions, or a zero-downtime requirement enter the picture, the semantic-validation and cutover risk described above is where outside help earns its cost — worth weighing against your own team's Oracle-and-PostgreSQL bench strength before deciding.
Get a Straight Answer on Your Setup
Tell us what you're running into. We read every message personally and reply within 24 hours with times for a free call.
