White Paper · PostgreSQL TCO Edition
Oracle to PostgreSQL Migration TCO Model: A 5-Year Spreadsheet for the Database EE Exit Decision
Last updated: June 2026
PostgreSQL is now the default destination for Oracle Database EE workloads that do not require Exadata-class performance or RAC-class consolidation. The technical migration is tractable for a significant share of enterprise workloads — community PostgreSQL, EDB Postgres Advanced Server, Aiven for PostgreSQL, Crunchy Postgres, AWS Aurora PostgreSQL-Compatible and Azure Database for PostgreSQL Flexible Server each ship a supported, production-grade target. The harder problem is the 5-year TCO model that justifies the migration to a CFO — workload class sizing, PostgreSQL distribution selection, migration labour cost, support model selection, residual Oracle right-size, and the Database EE retention play that Oracle will run against the migration business case. This 50-page methodology paper, paired with a 5-year TCO spreadsheet, is the buyer-side analysis — the workload-class costing matrix, the per-distribution support economics, the migration labour benchmarks, and the right-size Oracle residual that survives the migration.
Why Oracle's Database EE retention team relies on TCO opacity: Oracle's Database EE retention conversation assumes the customer does not have a defensible 5-year TCO model for PostgreSQL migration — meaning the migration cost is unknown, the support model is unsized, the migration labour is uncommitted, and the residual Oracle footprint is unmodelled. Each of those gaps lets Oracle's account team anchor the renewal at a premium against a hypothetical migration cost. The TCO Model is the spreadsheet that closes every one of those gaps — workload class by workload class, distribution by distribution, year by year.
What the TCO Model Covers
- Workload class sizing — the 9 workload classes that drive PostgreSQL migration economics: OLTP transactional, OLAP analytical, data warehousing, mixed workload, microservices/application backend, reporting, dev/test/staging, integration/ETL, archive — each with the typical workload size, the Oracle Database Option triggers, and the PostgreSQL target sizing
- PostgreSQL distribution selection — community PostgreSQL vs EDB Postgres Advanced Server (with Oracle compatibility layer) vs Aiven for PostgreSQL vs Crunchy Postgres vs AWS Aurora PostgreSQL-Compatible vs Azure Database for PostgreSQL Flexible Server, with the workload classes where each is the right answer
- Migration labour benchmark — the per-workload-class migration hour benchmark, the schema-conversion vs application-rewrite split, the testing window benchmark, and the parallel-running cost layer
- Support model selection — EDB subscription, Aiven managed support, Crunchy support, AWS Aurora hyperscaler support, Azure managed support, in-house Postgres team — with the per-workload-class economics and the operational risk model
- Residual Oracle right-size — the Oracle workloads that should NOT migrate (Exadata-class performance, RAC consolidation, GoldenGate Active-Active, deep Database Vault dependency), the residual Oracle footprint sizing, and the right-size Oracle Database EE renewal envelope that survives the migration programme
- 5-year cash flow — the year-by-year migration cost, support cost, residual Oracle support, and the cumulative savings curve plotted against the Do-Nothing baseline (continued Oracle Database EE + support escalation)
- Risk-adjusted TCO — the migration risk model, the schedule-overrun contingency, the dual-running buffer, and the documented variance ranges across comparable PostgreSQL migration programmes
- Oracle's expected retention play — the Database EE discount, the support holiday, the 23ai upgrade incentive, the OCI Cloud Lift carrot, the audit threat — each modelled against the migration TCO with the buyer-side counter
- Deal-shape for the Database EE renewal — even when migration is the right answer, the Database EE renewal that bridges the migration window needs negotiating. The deal-shape, the discount benchmark and the term-length pattern that does not over-commit during migration
- The 5-year TCO spreadsheet — the editable workbook with the workload-class costing matrix, the per-distribution support economics, the migration labour benchmark, the residual Oracle right-size, and the executive-summary CFO output
TCO Model Chapters
Chapter 01
Workload Class Sizing — The 9 Migration Classes
Chapter 02
PostgreSQL Distribution Selection by Workload
Chapter 03
Migration Labour Benchmark & Schedule
Chapter 04
Support Model Selection & Operational Risk
Chapter 05
Residual Oracle Right-Size & Non-Migrate Set
Chapter 06
5-Year Cash Flow vs Do-Nothing Baseline
Chapter 07
Risk-Adjusted TCO & Variance Ranges
Chapter 08
Oracle's Database EE Retention Counter-Plays
Chapter 09
Bridge Renewal Deal-Shape & Term Length
Chapter 10
5-Year TCO Spreadsheet — Documentation
Framework Insight 01
"The CFO question is not 'does PostgreSQL work technically'. It is 'what is the 5-year cash impact, risk-adjusted, against the Do-Nothing baseline'. Across documented PostgreSQL migration programmes, the 5-year cumulative saving against the Do-Nothing baseline runs 45–72% of the equivalent Oracle Database EE + support cost — but only for workload classes that meet the migration criteria. The TCO Model is the spreadsheet that produces the workload-by-workload number the CFO will sign against."
Framework Insight 02
"PostgreSQL migration is not a Database EE termination. The residual Oracle footprint — Exadata-class performance workloads, RAC-consolidated workloads, deep Database Vault dependencies — typically sits at 18–32% of the pre-migration Oracle estate. The TCO Model that wins inside the enterprise treats PostgreSQL as the 65–82% migration target and the right-size Oracle Database EE renewal as the protected residual, with a negotiated bridge renewal that funds the migration window without over-committing to a multi-year Oracle term."