In the first four parts of this series, we covered the architecture, economics, security, and migration mechanics. This final piece is the one that determines whether your Oracle Database@Azure program becomes a financial win or just an expensive change of venue.
How do you choose the right service tier, size it correctly, and license it in a way that actually captures the financial upside? This is not a simple pricing lookup. The Database@Azure catalog offers distinct services with different scaling behaviors, isolation characteristics, and licensing math.
First, Understand the Compute Metrics: ECPU vs. OCPU
The unit you use to measure compute depends on the underlying technology of the service. Getting this right is fundamental to your business case.
- ECPU (Exadata Compute Unit): The modern, elastic unit for all Exadata-based services (Dedicated, Exascale, and Autonomous). An ECPU represents the compute capacity of one physical core’s-worth of hyper-threaded processors. It allows for fine-grained scaling and, in some services, the ability to scale to zero.
- OCPU (Oracle CPU): The traditional unit for VM-based services (Base DB). An OCPU also represents one physical core with hyper-threading enabled. It is typically provisioned in larger, less granular increments.
The Database@Azure Service Catalog for EBS
These are not just “flavors.” They are distinct operating models designed for different EBS profiles.
| Service | Technology | Compute Unit | Key Use Case for EBS |
|---|---|---|---|
| Exadata Database Service on Dedicated Infrastructure (ExaDB-D) | Exadata | ECPUs | Large, mission-critical production EBS. Maximum performance and hardware isolation. |
| Exadata Database Service on Exascale Infrastructure (ExaDB-XS) | Exadata | ECPUs | Most strategic “middle” tier. Mid-tier production; dev/test consolidation with scale-to-zero capability. |
| Autonomous Database on Dedicated Infrastructure (ADB-D) | Exadata | ECPUs | Organizations desiring maximum automation for patching, tuning, and management. |
| Base Database Service | VM | OCPUs | Small EBS footprints (<2 TB); lightweight non-prod where Exadata-specific features aren’t needed. |
The Licensing Paths: BYOL vs. License Included
Everything flows from this decision.
- Bring Your Own License (BYOL): This model allows you to apply your existing, actively-supported Oracle Database licenses to Database@Azure. If you have a mature Oracle license portfolio, this is your primary path to significant cost savings.
- THE ULA TRAP: If your organization has an Oracle Unlimited License Agreement (ULA), understand this risk. Standard ULAs are for certifying your on-prem footprint. Cloud deployments do not automatically count toward your certification unless explicitly written into the contract. Deploying heavily on Database@Azure during a ULA term could leave you significantly under-certified at expiry. Engage your procurement and legal teams early.
- License Included (LI): The database software (Enterprise Edition plus key options) is bundled into the hourly service rate. This is ideal for short-lived environments, workloads needing options you don’t own (like RAC), or net-new companies without an existing Oracle license estate.
The Cloud Math: Why Database@Azure is More Efficient
The licensing conversion ratios on Database@Azure are materially more efficient than on native Azure VMs.
- On Native Azure VMs: Oracle’s policy states 2 vCPUs = 1 Oracle Processor License. You must license the maximum vCPU count of the VM SKU. Relying on “constrained vCPU” shapes is a high-risk strategy not formally recognized by Oracle LMS for reducing license liability.
- On Database@Azure (Exadata Services): The BYOL ratio is 8 ECPUs = 1 Oracle Processor License.
- On Database@Azure (Base DB Service): The BYOL ratio is 2 OCPUs = 1 Oracle Processor License.
Since 1 OCPU or 4 ECPUs deliver compute power roughly equivalent to 2 vCPUs, you are effectively getting twice the licensed compute capacity per Oracle Processor license compared to running on native Azure VMs, regardless of which Database@Azure service you choose.
Furthermore, Exadata Database Service includes critical database options like TDE, Diagnostics & Tuning Packs, and Data Masking & Subsetting, which often require separate, expensive licenses in a native VM build.
Matching Service Tiers to Your EBS Profiles: A Decision Guide
Question 1: What is my primary driver: performance, automation, or non-prod cost savings?
- Performance at Scale → ExaDB-D: For your largest production EBS database, where nothing less than dedicated Exadata hardware will do. While the hardware is dedicated, it now uses the modern, elastic ECPU metering model.
- Automation & Managed Services → ADB-D: If your goal is to minimize DBA overhead for patching, tuning, and security, ADB-D is the target.
- Non-Prod Cost Savings → ExaDB-XS: The ability to scale ECPUs down to zero on a VM cluster makes this incredibly cost-effective. You can shut down your dev/test environments overnight and on weekends, paying only for storage.
CRITICAL CERTIFICATION UPDATE: EBS on Autonomous Database Oracle E-Business Suite 12.2 is officially certified and supported on Autonomous Database on Dedicated Infrastructure (ADB-D). It is not certified on Autonomous Database Serverless (ADB-S). This is a game-changer for organizations wanting to modernize their EBS operations with a fully managed database service.
Question 2: What is the scale and character of my workload?
- Massive & Complex → ExaDB-D: Multi-terabyte EBS database with heavy batch processing and high concurrent user loads. ExaDB-D is the ideal platform for high-density database consolidation. A single Exadata system can host multiple VM Clusters, which in turn can host many databases. This allows you to consolidate dozens of non-prod EBS instances onto shared infrastructure, dramatically lowering your overall footprint and cost.
- Mid-Tier & General Purpose → ExaDB-XS: Your production is important but doesn’t require a dedicated quarter rack, or you want to consolidate dozens of non-prod instances onto a single, efficient platform.
- Small & Simple → Base DB: A smaller EBS footprint (typically under 2 TB) or for individual, lightweight non-prod instances. It uses the OCPU model on a VM-based architecture. It is crucial to understand the consolidation limitation of this service. While cost-effective for single instances, Base DB does not support high-density consolidation for EBS. Due to fundamental EBS application architecture constraints, you can only run one EBS database (as a Pluggable Database – PDB) per Container Database (CDB). Furthermore, each Base DB Virtual Machine can only host a single CDB. This creates a rigid 1:1 mapping: one VM for every single non-prod database copy. If you have 20 non-prod database instances, you will need 20 Base DB VMs. This stands in stark contrast to the many-to-one consolidation model offered by ExaDB-XS and ExaDB-D.
Question 3: What is my database version strategy?
- Migrate Now (Safe Bet) → Oracle Database 19c: The current long-term support release, 19c is the universal, stable, and fully certified landing zone for any EBS 12.2 migration happening today.
- Modernize on Arrival (Advanced) → Oracle Database 26ai: The latest release is certified with EBS 12.2, but the prerequisites are strict (EBS 12.2.14+, system schema migration, latest AD/TXK updates, etc.). This is a compelling target for its new features, but plan for it as a post-migration upgrade project.
The Commercial Levers: Your CFO’s Guide to Database@Azure
- MACC (Microsoft Azure Consumption Commitment): All Database@Azure spend—infrastructure and license-included fees—counts 1:1 toward your organization’s MACC. This allows you to fund your Oracle modernization using your committed Azure budget.
- Oracle Support Rewards: By running on OCI infrastructure (which powers Database@Azure), you earn “rewards” that can be applied as a credit against your Oracle Technology software support bill. You earn a credit of 25 cents for every dollar spent (or 33 cents for ULA customers). This directly reduces your Oracle support invoice but requires an active OCI commercial agreement.
- Procurement: You buy Database@Azure through the Azure Marketplace. ExaDB-XS and Base DB can be consumed Pay-as-you-go, while ExaDB-D and ADB-D require a negotiated Private Offer.
The Bottom Line
Oracle Database@Azure is a comprehensive, four-tier portfolio. Your financial success hinges on making three deliberate choices before you migrate:
- License Model: Align your BYOL vs. LI decision with your actual license holdings, avoiding the ULA trap.
- Service Tier: Select the right service (ExaDB-D, ExaDB-XS, Base DB, or ADB-D) based on your specific requirements for performance, isolation, automation, and cost, using the correct ECPU or OCPU metric for sizing.
- Commercials: Structure your procurement to maximize MACC drawdown and capture Oracle Support Rewards.
Get these right, and you can fundamentally transform the economics of your Oracle estate while finally closing the door on your last datacenter.
E-Business Suite on Azure with Oracle Database@Azure — Series
- Introduction: The Last Datacenter Exit: Migrating Oracle E-Business Suite to Azure with Database@Azure
- Part 1: The EBS Cloud Reality Check — Why “Lift and Shift to VMs” Doesn’t Work for ERP
- Part 2: Oracle EBS Economics: Oracle on Azure VMs vs Oracle Database@Azure — A Real TCO Comparison
- Part 3: Resilient ERP — Backup, Recovery, and Cyber-Resiliency with Database@Azure
- Part 4: EBS Platform Move — Unix to Azure Linux with Smaller Cutovers
- Part 5: Picking the Right Database@Azure Service for EBS — Dedicated Exadata, Exascale, Base DB, and How to License Them