An Oracle Database vs PostgreSQL comparison rarely comes down to the licence — it comes down to support, migration cost, and the audit Oracle runs when you cancel.

The Postgres licence is free — what actually costs money

PostgreSQL is released under the PostgreSQL Licence, a permissive open-source licence comparable to MIT or BSD. There is no per-core fee, no per-user fee, no revenue-based fee, and no audit risk attached to the open-source database itself.

The real enterprise costs are four things:

• Commercial support from EnterpriseDB, Crunchy Data, 2ndQuadrant (now part of EDB), or a regional Postgres specialist — typically $30,000 to $80,000 per server per year for enterprise-grade contracts
• Managed-service surcharges on AWS RDS for Postgres, Aurora PostgreSQL, Azure Database for PostgreSQL Flexible Server, or Google Cloud SQL for Postgres — usually a 25 to 45 percent uplift over equivalent self-managed compute
• Internal operations cost — DBA staffing, monitoring tooling, training. Usually lower per workload than Oracle, but rarely zero.
• The migration project itself — schema and PL/SQL conversion, application testing, parallel running. Treated as a one-off; payback is usually 12 to 22 months from the Oracle saving.

The net annual TCO comparison for a 200-core enterprise workload typically lands at 18 to 30 percent of the Oracle Database EE equivalent — even after fully loaded enterprise Postgres support contracts.

Capability comparison in 2026

The capability gap that justified Oracle Database's premium for decades has narrowed dramatically. PostgreSQL 15 and 16 close most of the operational gap; well-funded extensions close the rest.

The remaining genuine Oracle-only territory: shared-storage active-active (RAC), Exadata-specific optimisations, deep Spatial 3D and network data, and a small set of PL/SQL constructs that require manual rewrite. For most enterprise OLTP, reporting, data warehousing under 100 TB, and modern application back-ends, PostgreSQL is functionally complete.

Postgres support: EnterpriseDB, Crunchy, AWS, Azure

Production Postgres without commercial support is a defensible choice for some workloads — but most enterprises pick one of four routes.

• EnterpriseDB (EDB) offers Postgres support plus Oracle-compatibility features (EDB Postgres Advanced Server) including PL/SQL-like extensions, DBA tooling, and migration accelerators. EDB pricing typically lands at $35K to $80K per server per year for Standard / Enterprise tiers.
• Crunchy Data focuses on pure open-source Postgres with strong security, HA, and Kubernetes-native deployment. Crunchy support contracts typically run $25K to $60K per cluster per year.
• AWS RDS for PostgreSQL and Aurora PostgreSQL-Compatible bundle support with the managed-service fee. Aurora's Postgres-compatible engine is a separate product with its own SLA and architecture; it is not vanilla Postgres but is API-compatible.
• Azure Database for PostgreSQL Flexible Server and Google Cloud SQL for PostgreSQL similarly bundle managed-service operations with support. Microsoft and Google's Postgres support quality has improved markedly since 2023.

The buyer-side advice on Postgres support: pick the route that matches your operational model. If you have an on-premise or hybrid estate with strong internal Postgres skills, EDB or Crunchy. If you are cloud-native and want managed-service convenience, AWS RDS or Aurora. If you are heavily Azure or GCP, the native managed services are mature enough to commit to.

5-year TCO worked example

Scenario: 200-core Oracle Database EE workload with Partitioning, Advanced Compression, Diagnostics Pack, and one DR site (Active Data Guard). Migration target: managed PostgreSQL on AWS RDS, plus EDB support for self-managed cluster sites.

The headline 71 percent saving is real, but the migration project is real cost and real risk. The break-even point for this profile is month 14 from cut-over. If your Oracle support is currently more than $1M per year, the math works. If it is below $400K per year and the codebase is heavily PL/SQL-dependent, it may not.

PL/SQL conversion and migration effort

The Oracle to PostgreSQL migration always concentrates effort in three places: schema conversion, PL/SQL conversion, and the testing-reconciliation cycle.

Schema conversion is the easy part. Ora2pg (open-source) and AWS Schema Conversion Tool typically convert 75 to 92 percent of Oracle schemas automatically. The remaining manual work is around data types (NUMBER precision, DATE timezone handling), VARCHAR2 to TEXT/VARCHAR, identity columns, and Oracle-specific defaults.

PL/SQL conversion is where the work concentrates. PostgreSQL's PL/pgSQL is broadly compatible with PL/SQL, but several constructs require manual rewriting: packages (split into schemas plus functions), Oracle-specific built-ins (e.g. DBMS_OUTPUT, DBMS_LOB), autonomous transactions, and certain cursor handling patterns. For a 200,000-line PL/SQL codebase, plan 6 to 9 person-months. EDB Postgres Advanced Server reduces this work significantly by providing native Oracle-compatibility extensions.

Testing and reconciliation is the longest phase. Every report, every batch job, every application connection has to produce the same numbers from Postgres as from Oracle. Plan 30 to 50 percent of the project timeline for this phase.

Realistic timeline for a 200-core mid-sized enterprise: 12 to 24 months end-to-end. Realistic cost: $1.2M to $3.5M depending on PL/SQL complexity, application count, and SI rates.

AWS RDS, Aurora-Postgres, Azure Flexible Server

The cloud managed-Postgres landscape has matured quickly. Three serious enterprise options:

• AWS Aurora PostgreSQL-Compatible — a Postgres-API-compatible engine on AWS's own distributed-storage architecture. Higher cost than vanilla RDS for Postgres but materially better HA / DR characteristics. Often the chosen destination for Oracle-to-AWS migrations of OLTP workloads. See our Oracle vs Aurora comparison for detail.
• Azure Database for PostgreSQL Flexible Server — Microsoft's mature Postgres managed service. Strong integration with Azure AD authentication, Private Link networking, and Azure Defender for security. Common destination for organisations already deeply Microsoft-aligned.
• AWS RDS for PostgreSQL (non-Aurora) — vanilla open-source Postgres in a managed offering. Cheaper than Aurora; lower HA guarantees. Often used for development, dev/test, and smaller production workloads.

For Google Cloud, Cloud SQL for PostgreSQL is mature; AlloyDB is Google's higher-performance Postgres-compatible engine and is covered in our Oracle vs Google AlloyDB comparison.

The Oracle audit triggered by your Postgres move

Cancelling Oracle Database EE support is one of the most reliable LMS triggers. We have not seen an Oracle Database support termination in the last three years that did not result in some form of LMS engagement letter inside six months.

The pattern is predictable. A "courtesy review" letter arrives 30 to 120 days after the non-renewal notice. The opening claim is typically a back-licence position covering perceived under-licensing across the entire Oracle estate — not just the products you dropped. Common attack vectors:

• VMware soft partitioning. Even after Postgres migration, Oracle may claim historic under-licensing on the cluster where Oracle previously ran.
• Options usage. If Partitioning, Advanced Compression, or Diagnostics Pack appears in Oracle Database audit scripts during the discovery scan, Oracle will claim usage.
• Named User Plus minimums. NUP licences carry per-Processor minimums; if your historical user count exceeded the minimum, Oracle may claim under-licensing for the lookback period.
• Java SE deployments. The Java SE Universal Subscription audit is a parallel track — and a known fallback when Database audit defence holds firm.

Defence is buyer-side, evidence-based, and starts before the non-renewal notice goes out. The Effective Licence Position, virtualisation configuration documentation, NUP audit, options usage history, and decommission record all need to be filed before the notice. With that pack, settlement outcomes typically land between 18 and 32 percent of Oracle's opening claim. Without it, average is 60 to 75 percent.

When PostgreSQL is NOT the right answer

Buyer-side advice means saying no where it would harm the client. Four situations where Oracle Database is the right answer to keep — at least for this workload:

1. Active RAC dependency. Shared-storage active-active with sub-second failover is a real Oracle differentiator. Postgres alternatives (BDR, multi-master patterns) are not equivalent at enterprise scale.
2. Exadata-specific optimisation. If the workload depends on Smart Scan, Storage Indexes, or Hybrid Columnar Compression, the migration cost may exceed the lifetime saving.
3. Heavy Spatial 3D / Network data. PostGIS is excellent but does not cover every Oracle Spatial scenario. Validate the specific functions in use.
4. Million-line PL/SQL estates with thousands of dependent applications. The migration project cost rises non-linearly with codebase size. Above 1 million lines of PL/SQL, the project economics are usually marginal.

For everyone else — and that is most large Oracle estates — Postgres is the destination most worth modelling.

FAQ — Oracle Database vs PostgreSQL

Is PostgreSQL really free for enterprise use?

Yes — the open-source PostgreSQL licence is free for any commercial use, with no per-core, per-user, or revenue-based fees. The real enterprise cost is support: either commercial support from EnterpriseDB, Crunchy Data, or equivalent; or managed-service charges on AWS RDS, Aurora, Azure Flexible Server, or Google Cloud SQL. Most enterprises budget $80K to $240K per year for fully-supported Postgres at enterprise scale.

What features does Oracle have that PostgreSQL does not?

The narrowing gap: PostgreSQL 16 covers partitioning, logical replication, advanced JSON (JSONB), PostGIS for geospatial, full-text search, materialized views, parallel queries, columnar storage (via Citus or Hydra), and time-series (via TimescaleDB). What Oracle still leads on: shared-storage active-active RAC, Spatial 3D and network data, deep PL/SQL ecosystem, Exadata-specific optimisations. For most enterprise workloads, the gap is operational, not capability.

How hard is an Oracle to PostgreSQL migration?

Schema conversion is largely automated using Ora2pg or AWS SCT — 60 to 85 percent of typical workloads convert without manual intervention. PL/SQL conversion is where the work concentrates. A 200,000-line PL/SQL codebase typically needs 6 to 9 person-months of conversion plus testing. Plan 12 to 24 months end-to-end for a mid-sized estate.

What happens to Oracle support during a Postgres migration?

Plan the cut-over to land at or before the next Oracle support renewal. Send the formal non-renewal notice on time and prepare the audit defence pack before the notice goes out. Expect an LMS engagement letter within 30 to 180 days — a known Oracle response to support cancellation. Defend with evidence, do not just react.

Should we go to EnterpriseDB or vanilla Postgres?

EDB Postgres Advanced Server reduces PL/SQL migration effort with Oracle-compatibility extensions, but ties you to a commercial vendor. Vanilla Postgres (community-supported, optionally with Crunchy or 2ndQuadrant) preserves the open-source thesis but requires more manual PL/SQL conversion. For estates with heavy PL/SQL, EDB usually pays for itself in migration cost savings. For greenfield or thin-PL/SQL estates, vanilla is the right call.

Does Oracle ever offer to match Postgres economics?

For workloads where a credible Postgres migration is in flight, Oracle's account team may offer aggressive discounting — sometimes Oracle Database Standard Edition 2 at heavy discount, sometimes a cloud-credit-funded migration to Autonomous Database. Benchmark the offer against the 5-year Postgres TCO; the migration project pays back inside 18 months in most scenarios where the Postgres math worked in the first place.

Independence statement: Oracle Licensing Experts is an independent buyer-side advisory firm. Not affiliated with Oracle Corporation. We have no commercial relationship with EnterpriseDB, Crunchy Data, AWS, Azure, or Google Cloud. All numbers above reflect published list prices and benchmark engagement data.

Related guides