Applies toAutonomous Database (Serverless and Dedicated), Base Database Service (VM DB systems), Exadata Database Service (Dedicated, Exascale, Cloud@Customer), Oracle Database@Azure / @AWS / @Google Cloud
Who manages what
| Autonomous Database | Base Database Service | Exadata Database Service | Database@Hyperscaler | |
|---|---|---|---|---|
| Patching | Automatic | You trigger (tooling provided) | You trigger (tooling provided) | Depends on service (Autonomous or Exadata) |
| OS / SYS access | No (database-level access only) | Yes | Yes (VM cluster) | As for the underlying service |
| Scaling | Online ECPU and storage auto scaling | CPU scaling, storage grow | Online CPU scaling, large scale | As underlying service |
| HA | Built in; Autonomous Data Guard | Single node, RAC (2-node), Data Guard | RAC, Data Guard | As underlying service |
| Best for | New apps, APEX, analytics, low-ops estates | Small/medium databases needing full control | Large, critical, consolidated estates | Apps already in Azure/AWS/Google needing low-latency Oracle |
Decision path
Need OS access, custom software on the DB host, unsupported features or specific patch levels?
├─ no → Can the app run on Autonomous (feature/compat check)?
│ ├─ yes → Autonomous Database (Serverless; Dedicated for isolation/control of updates)
│ └─ no → Base Database or Exadata
└─ yes → Size and criticality?
├─ Small/medium, few databases → Base Database Service (RAC 2-node if HA needed)
└─ Large, many databases, RAC at scale, high I/O → Exadata Database Service
App tier lives in Azure, AWS or Google Cloud and latency matters?
└─ consider Oracle Database@Azure/AWS/Google (Exadata or Autonomous in the hyperscaler's data centre)
Compatibility checks before choosing Autonomous
- Features and privileges the app or vendor needs (OS access, specific init parameters, some database options,
SYSscripts). - Vendor support statement for Autonomous Database.
- Character set and time zone needs.
- Use the Cloud Premigration Advisor Tool (CPAT) or migration assessment to find blockers.
Plan these with the choice
| Topic | Questions |
|---|---|
| HA | Single instance acceptable? RAC needed? Local standby? |
| DR | Cross-region standby (Data Guard / Autonomous Data Guard), RPO/RTO, Full Stack DR orchestration |
| Network | Private endpoints, latency to app tier, FastConnect/interconnect for hybrid apps |
| Security | Data Safe, TDE key management (Oracle-managed vs customer-managed in Vault), Database Vault needs |
| Licensing | License Included vs BYOL, editions and options really used |
| Operations | Patch windows and who triggers them, monitoring (Database Management, Ops Insights) |
Typical mappings
| Scenario | Choice |
|---|---|
| New internal app, APEX, reporting | Autonomous Database Serverless |
| ERP/vendor app requiring OS access and specific patch levels | Base Database (or Exadata for size) |
| Consolidating 100+ databases from on-prem Exadata | Exadata Database Service |
| .NET app on Azure needing Oracle with low latency | Oracle Database@Azure |
| Data residency requiring on-prem hosting with cloud operations | Exadata Cloud@Customer |
Tip
Decide per database, not per estate. Most organisations end up with a mix: Autonomous for new and simple workloads, Exadata or Base Database for vendor and legacy systems.
Checklist
- Control requirements (OS, SYS, patch timing) listed
- Autonomous compatibility assessed (CPAT/vendor support)
- Size, criticality and HA needs mapped to service
- App location and latency considered (Database@Hyperscaler)
- DR, network, security and licensing planned together
- Decision recorded per database