PostgreSQL removes the license line. It does not remove the bill. Here is the five year model skeleton, the five places the zero fee gets eaten, the workload boundaries, and the renewal leverage the analysis buys even if you stay.
PostgreSQL carries no license fee, while Oracle Database charges per processor or per Named User Plus plus options and support. The decision is exit math: a five year model with the right lines in it, workload boundaries drawn honestly, and the migration bill counted in full.
PostgreSQL is a mature open source relational database released under the permissive terms on the PostgreSQL licence page. Oracle Database is commercial software priced in the Oracle Technology Price List.
Everyone knows the headline. What separates a fundable business case from a slide is the model behind it, and that model is what this page builds.
Oracle sells a metered right to run, metered by processor or by named user, with separately priced options and a support contract at roughly 22 percent of net license per year. PostgreSQL grants an unmetered right to run, and monetizes nothing, which relocates every cost into things you choose to buy or build.
Our annotated read of the technology price list carries the full line items. For metric mechanics and edition rules, the Oracle Database licensing pillar is the reference.
The PostgreSQL project ships the engine free under its permissive license. What enterprises actually pay for is a commercial support subscription, the engineering to run high availability properly, and the one time cost of getting there.
A comparison is only defensible if both columns describe the same service. Fix these six variables before a single number goes in:
In five places, and a good model names them as line items rather than burying them in a contingency row. None of them erase the saving in a typical estate. Together they decide how much of it survives.
The five costs that replace the license line
| Cost line | What it buys | How to source the number |
|---|---|---|
| Support subscription | Named vendor backing with response times | Three written quotes, priced per instance or per core |
| High availability tooling | Failover, connection pooling, backup orchestration | Engineering days from your platform team's estimate |
| Managed service premium | A cloud provider running it for you | Published cloud price sheets for your instance sizes |
| Migration labor | Conversion, remediation, testing, cutover | Two independent fixed scope proposals |
| People and skills | Hiring or training the operating team | Real salary and training budget lines |
Enterprises that replace Oracle support with a commercial PostgreSQL vendor pay a genuine annual fee, and pricing models vary widely between vendors and metrics. Resist quoting an analyst average. Three written quotes against your actual instance list is the only number a CFO should accept.
Version currency belongs in the picture too. PostgreSQL major releases arrive yearly with roughly five years of community support each, so the model should include a recurring minor line for upgrade engineering. It is small, and pretending it is zero invites the first hostile question in review.
Oracle sells failover as product. PostgreSQL delivers streaming replication free and leaves orchestration to tooling such as Patroni, pgBackRest, and a connection pooler, assembled and tested by your team. The software costs nothing. The assembly, the runbooks, and the failover testing are the budget line.
Running PostgreSQL as a cloud managed service removes the availability engineering line and adds an hourly premium over raw compute, plus storage and egress at the provider's sheet. Price it from the published sheets for your actual instance sizes across the full environment count.
The premium is usually worth paying for small teams. It is a real cost line all the same, and models that treat managed PostgreSQL as free capacity overstate the saving.
An Oracle DBA team does not become a PostgreSQL platform team by memo. Budget training, some hiring, and a period of reduced velocity, and put real salary numbers on it. In our models this line was material for the first two years, then converged toward the Oracle baseline.
Nine lines per segment, one column per platform, every number sourced. The skeleton below is the deliverable that survives finance review. Fill it per workload segment, never for the estate as a whole.
Five year model skeleton, per workload segment
| Line | Oracle column | PostgreSQL column |
|---|---|---|
| License acquisition | Zero if owned, list less negotiated terms if growing | Zero |
| Annual support or subscription | 22 percent stream, five years, with uplifts | Vendor quote, five years |
| Options and packs | Each licensed option's line and support | Zero, or extension support if commercial |
| Infrastructure | Held equal by design | Held equal by design |
| Availability tooling | Included or optioned, for example Active Data Guard | Engineering days plus ongoing operation |
| People | Current team cost | Team cost after hiring or retraining |
| Migration, one time | Zero | Fixed scope proposal plus internal testing time |
| Dual running | Zero | Months of parallel operation during cutover |
| Risk contingency | Audit and renewal exposure | Schedule overrun on conversion and testing |
Two disciplines keep the skeleton honest. First, the Oracle column uses your negotiated reality, not list, wherever contracts exist. Second, both columns carry the same growth assumption, because a comparison where one platform mysteriously needs less capacity is answering a different question.
An 8 processor segment running Enterprise Edition with Partitioning and Diagnostics Pack carries 66,500 dollars per processor of license basis, so a 532,000 dollar base. The support stream on that basis runs about 117,000 dollars a year, or roughly 585,000 dollars across the five year horizon before any uplift.
For an owned estate, that support stream plus any growth purchases is the avoidable Oracle cost. That is the number the PostgreSQL column has to beat, not the license sticker.
Every PostgreSQL line should carry a source you could hand to an auditor: written support quotes, your platform team's estimate in days, cloud price sheets, and two migration proposals. Where a number cannot be sourced yet, leave the cell marked open rather than borrowing one from a vendor deck.
One warning from the engagement file: the models that failed review all failed the same way, an unsourced migration line defended by optimism. The models that funded programs carried two external proposals and a named contingency. The difference was credibility, not arithmetic.
A usable rule of thumb from the models we built: when the five year avoidable Oracle cost exceeds the sourced migration bill plus contingency, and no hard dependency blocks the move, the segment qualifies. When annual Oracle support alone would repay the migration inside about three years, it qualifies easily.
White Paper · Oracle Database
Oracle to PostgreSQL Migration
The Oracle exit business case, worked. Read it free.
Present the result as a range, not a point. A model that says the segment saves between one number and another, depending on the two sourced migration proposals, reads as honest. A single figure to the dollar reads as manufactured, because it is.
Materially, and this is the return nobody puts in the spreadsheet. A sourced, segmented exit model changes Oracle's behavior at renewal even for the workloads that stay, because the account team can read a credible alternative as easily as you can.
Run the exit analysis even if you expect to stay. In several of the engagements behind this page, the model never triggered a migration and still paid for itself in the renewal it reshaped.
Draw the boundary by dependency, not by preference. The scoring that matters is how much Oracle specific machinery the workload actually exercises, and the answer is usually in the feature usage views, not in anyone's opinion.
Segment sizing matters more than segment count. Three segments, small, standard, and dependent, cover most estates. A model with a dozen segments impresses nobody and stalls in review.
Middleware follows the same segmentation logic, and Oracle database exits often unlock it next. The parallel case for the application tier is built in our middleware migration business case for CFOs.
Score each workload on five tests before assigning it a column:
Workloads failing none of the five move first. Workloads failing two or more usually stay until an application refresh changes the answer.
The cost scales with Oracle feature density, and testing dominates it. Tooling converts schemas and much of the code mechanically. Nobody has automated proving that the converted system behaves identically under production load, and that proof is most of the bill.
Move reference data and reporting replicas first, transactional systems second, and the systems of record last, each behind a reconciliation gate. Early waves build the team's competence on workloads that can tolerate a rough week.
Keep the Oracle licenses of a migrated segment parked until the reconciliation gate closes. Terminating support in the same month as cutover looks efficient and removes your rollback path at the moment you are most likely to need it.
The common pitch, often from the Oracle account team, is that PostgreSQL looks cheaper on license but costs more once you add support, risk, and engineering, so the move rarely pays off. We disagree with the blanket version of that claim. In the comparisons Fredrik Filipsson modeled, PostgreSQL won decisively for new and non critical workloads where there was no migration to fund, and the Oracle support stream alone often exceeded the entire PostgreSQL run cost. The buyer side move is to segment the estate, move the workloads that carry no migration tax first, and keep Oracle only where a specific feature or scale dependency justifies it. Treating it as all or nothing favors the incumbent.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
PostgreSQL has no license fee. That is not the same as free. Build the nine line model per segment and let the arithmetic decide.
Finance will ask who owns the model afterward. Assign it to the software asset management function and refresh it annually, because a stale exit model loses its negotiating value the first time Oracle's team spots an outdated assumption in it.
The software is free under a permissive open source license with no user or processor metering. Operating it is not free: support subscriptions, availability engineering, and people replace the license line, which is why the model matters.
Per processor with the core factor applied, or per Named User Plus, plus separately priced options and an annual support stream near 22 percent of net license. The options are what most buyers forget to count.
The workload, the environment count including non production and disaster recovery, the availability targets, the support quality, and the operating team. Vary any of those and the two columns describe different services.
Migration labor, and inside it, testing. Conversion tooling handles the mechanical work, but proving identical behavior under production load is human effort, which is why sourced fixed scope proposals belong in the model.
When dependency is hard: dense PL/SQL, RAC based clustering, an ISV that certifies only Oracle, or genuine engineered system scale. In those segments the conversion bill and risk outrun the support saving inside five years.
Often yes in function: native partitioning, streaming replication for standby reading, and extensions cover much of what Oracle options charge for. Active active clustering in the RAC sense is the notable gap.
Yes, and most successful exits do exactly that for years. Segment the estate, move what qualifies, and keep the dependent core on Oracle while the support base shrinks around it.
No. Redress Compliance is 100 percent buyer side, with no resale and no implementation revenue on either platform. We build the model and negotiate the Oracle side of it.
Migrating Oracle to PostgreSQL removes the licence and the 22 percent support annuity. The break even math, what migrates cleanly, and the negotiation angle.
Used across more than five hundred enterprise engagements. Independent. Buyer side. Built for procurement leaders running the next renewal cycle.
