Applies toOracle Database 19c/23ai workloads; OCI Base Database, Exadata Database Service, Autonomous Database; Oracle Database@Azure and Oracle Database@AWS; Amazon RDS for Oracle; Oracle on Azure VMs or EC2
Targets compared
| Target | Operating model | RAC/Exadata | Notes |
|---|---|---|---|
| OCI Base Database | Oracle-managed infrastructure, you manage DB | RAC available on VM DB systems | Close to on-prem experience |
| OCI Exadata Database Service | Dedicated Exadata, you manage DBs | Yes | Large, performance-critical estates |
| Autonomous Database | Fully managed (patching, tuning, backups) | Exadata-based | Less control; app compatibility to check |
| Oracle Database@Azure / @AWS | Exadata/Autonomous inside the hyperscaler data center, operated by Oracle | Yes | Low latency to apps in Azure/AWS; billing via the hyperscaler marketplace |
| Amazon RDS for Oracle | AWS-managed single instance with Multi-AZ | No RAC | Some options/features unsupported; check list |
| Oracle on Azure VMs / EC2 | Self-managed | No RAC (not supported on these clouds) | Full control; licensing rules for authorized clouds apply |
Check current availability by region and each service's supported features.
Questions that decide it
- Do you need RAC or Exadata features (smart scan, HCC, very high I/O)? → OCI, Oracle Database@Azure/AWS.
- Where are the applications? Latency-sensitive apps in Azure or AWS favour Database@Azure/AWS or in-cloud options rather than cross-cloud links.
- Which options and packs are used? (Partitioning, Advanced Compression, Diagnostics/Tuning packs, etc.) Check each target's support and licensing.
- Licensing: bring-your-own-license vs license-included, core factor rules on authorized cloud environments; involve licensing specialists.
- Who will operate it? Managed services reduce DBA work but restrict OS access and some features.
- Migration path and downtime: Data Guard, GoldenGate, Zero Downtime Migration, Data Pump, DMS (see the Oracle transformation posts).
Common outcomes
| Situation | Often chosen |
|---|---|
| Large Exadata estate, apps moving to Azure | Oracle Database@Azure |
| Standard single-instance databases, AWS-centric | RDS for Oracle |
| Packaged apps needing OS access or unsupported options | VMs (self-managed) or OCI Base Database |
| Modernising toward less DBA effort | Autonomous Database after compatibility testing |
| Leaving Oracle entirely | PostgreSQL refactor (see the Ora2Pg post) |
Proof before commitment
- Run AWR-based sizing and test a representative workload on the target.
- Validate backup/restore, DR and patching processes.
- Confirm monitoring and access for your DBA team.
Warning
Licensing rules differ sharply between targets and can dominate total cost. Get a written licensing assessment for the chosen target before migration starts.
Checklist
- Features, options and packs inventoried
- Application location and latency needs known
- Licensing assessed per target
- Operating model agreed
- Migration method chosen
- Workload tested on target