Blog

  • ExaDB-XS vs ExaDB-D – When to choose ExaDB-XS

    Let’s compare Exadata Database Service on Exascale Infrastructure (ExaDB-XS) and Exadata Database Service on Dedicated Infrastructure (ExaDB-D) and review how to choose between these services. Both Oracle Database services run on powerful Exadata hardware within the Oracle Cloud Infrastructure (OCI) public cloud, but they differ in their underlying infrastructure model and characteristics.

    • Exadata Database Service on Dedicated Infrastructure (ExaDB-D):
      • Runs your Oracle databases on dedicated Exadata database servers and storage servers physically allocated solely to you within an OCI region. Think of it as single-tenant at the hardware infrastructure level, providing maximum isolation in the public cloud. You start with two database nodes and three storage servers.
    • Exadata Database Service on Exascale Infrastructure (ExaDB-XS):
      • Runs your Oracle databases on the shared infrastructure of Exadata compute and storage resources within OCI. Exascale architecture decouples compute and storage for greater flexibility and elasticity. Consider it multi-tenant at the hardware infrastructure level, though your VMs provide logical isolation. Instead of dedicated database servers and storage, you get a dedicated Exadata cluster with dedicated CPU and Storage.

    2. Key Differences and Decision Points:

    FeatureExaDB-XSExaDB-DDecision Driver
    InfrastructureShared, multi-tenant pools of Exadata compute & Exascale storageDedicated, physically isolated Exadata compute & storage serversIsolation: Choose D for maximum physical isolation. XS offers VM-level isolation on shared hardware.
    IsolationLogical isolation via VM clusters on shared hardwarePhysical isolation with dedicated serversCompliance/Security: D meets stricter requirements for physical separation.
    ScalabilityHyper-elastic; fine-grained scaling of ECPUs & Exascale Vault storageScales ECPUs/OCPUs dynamically; infrastructure scales by adding dedicated serversElasticity: XS offers more granular scaling, especially for storage, and potentially faster VM provisioning.
    Minimum SizeLow entry point (starts with 8 ECPUs, 300 GB storage)Higher entry point (requires minimum server configuration, 2 DB Servers + 3 Storage Servers)Cost/Starting Small: XS is more cost-effective for smaller workloads or starting new projects.
    Cost ModelGenerally lower entry cost; pay-per-use compute & storageHigher entry cost for infrastructure; pay-per-use computeBudget: XS provides Exadata power at a potentially lower cost, especially initially.
    PerformanceHigh Exadata performance on shared infra; benefits from Exascale arch.Predictable high Exadata performance on dedicated resourcesPredictability: D offers the most predictable performance baseline, free from potential “noisy neighbors”.
    Storage ManagementAbstracted via Exascale Vault; simplified scalingManaged via ASM across dedicated storage serversSimplicity: XS simplifies storage management (no need to manage ASM allocation across servers).
    MaintenanceUnderlying host maintenance may require scheduled VM restart/migrationMaintenance scheduled for the dedicated systemControl: D may offer more perceived control over infrastructure maintenance windows (though both managed by Oracle).
    Key FeaturesExascale architecture (direct I/O, RDMA), efficient thin cloning. Supports DB 23ai.Established platform, supports DB versions 19c and 23ai.Specific Needs: XS is ideal for leveraging efficient clones. Check DB version support for XS if not using 23ai.
    VM PortabilityHigh; VM filesystems on shared storage enable easier migrationLower; VM filesystems traditionally tied more closely to local compute resourcesFlexibility: XS architecture facilitates easier movement of VMs across underlying physical hardware.

    3. When to Choose ExaDB-XS (Exascale Infrastructure):

    • Cost Sensitivity: You need the power of Exadata but require a lower entry cost than dedicated hardware. Consolidate various smaller databases that demand high performance.
    • Elasticity is Key: Your workload is variable or unpredictable, and you need the ability to scale computing resources up or down quickly and granularly.
    • Starting Small: You are deploying a new application or migrating smaller workloads and want to start with a minimal footprint and grow later.
    • Development & Testing: You need to rapidly provision/de-provision environments and leverage efficient database cloning (thin clones) for multiple developers or test cycles.  
    • Simplified Storage Management: You prefer an abstracted storage layer (Exascale Vault) that does not require managing ASM allocations across specific storage servers.
    • Physical Isolation Not Mandatory: Logical isolation provided by VMs on shared infrastructure meets your security and compliance needs.

    4. When to Choose ExaDB-D (Dedicated Infrastructure):

    • Maximum Isolation Required: Your security policies, compliance regulations (e.g., certain financial or government standards), or internal governance demand physically isolated hardware.
    • Utmost Performance Predictability: You need guaranteed performance levels based entirely on your workloads running on dedicated, non-shared resources.
    • Large-Scale Consolidation: You consolidate numerous or very large databases onto a powerful, isolated platform. If the database storage exceeds 90TB, ExaDB-D would be more cost-effective, irrespective of the ECPUs required.
    • Migrating Existing Exadata: Moving a significant on-premises Exadata workload to the cloud requires equivalent dedicated resources.
    • Specific Compliance: Regulations explicitly mandate single-tenant hardware, even within the cloud.

    5. Price Comparison

    With ExaDB-D, you get dedicated usable storage of 240 TB. This allows you to allocate up to 192 TB for databases (without local backup) or up to 96 TB with local backup. Taking just the storage vault cost for 90TB in ExaDB-XS almost matches the infrastructure cost for 2 database servers (up to 1520 ECPUs) and 3 storage servers (up to 240 TB usable space). So you cannot determine if ExaDB-D or ExaDB-XS will be price-performant just by looking at the ECPU requirement.

    Let me show this with two sample Bill of Materials (BoM).  Since the blog template width is limited, here are the SKU descriptions used in the cost estimate.

    SKUExadata Database Service – ExaDB-XS
    B109355Oracle Exadata Exascale RDMA Compute Infrastructure (ECPU Per Hour)
    B107951Oracle Exadata Exascale VM Filesystem Storage (Gigabyte (GB) Storage Capacity Per Month)
    B107952Oracle Exadata Exascale Smart Database Storage (Gigabyte (GB) Storage Capacity Per Month)
    B109375Oracle Exadata Exascale Additional Flash Cache (Gigabyte Per Hour)
    B109357Oracle Exadata Exascale Database ECPU – BYOL (ECPU Per Hour)
     SKUExadata Database Service – ExaDB-D
    B110629Exadata Cloud Infrastructure – Storage Server – X11M (Hosted Environment Per Hour)
    B110627Exadata Cloud Infrastructure – Database Server – X11M (Hosted Environment Per Hour)
    B110632Exadata Database ECPU – Dedicated Infrastructure – BYOL (ECPU Per Hour)

    Table 1: Large database storage footprint (90TB). ECPU allocation is very small, but ExaDB-XS is still expensive, and going with ExaDB-D makes it cheaper to scale.

    Part SKUPart QtyInstance QtyUsage QtyUnit PriceMonthly Cost
     ExaDB-XS     $ 11,650.48
    B109355161730 $0.025000 $292.00
    B10795128011 $0.042500 $11.90
    B1079529000011 $0.115600 $10,404.00
    B10937501730 $0.000500 $          –  
    B109357161730 $0.080700 $ 942.58
     ExaDB-D        $ 11,539.26
    B11062931730 $2.903200 $6,358.01
    B11062721730 $2.903200 $4,238.67
    B110632161730 $0.080700 $942.58
    Difference-1%

    Table 2: Smaller storage footprint (30TB). Plenty of ECPUs allocated on ExaDB-XS, still, it is cheaper than ExaDB-D.

    Part SKUPart QtyInstance QtyUsage QtyUnit PriceMonthly Cost
     ExaDB-XS     $23,233.12
    B1093552561730 $0.025000 $4,672.00
    B10795128011 $0.042500 $11.90
    B1079523000011 $0.115600 $3,468.00
    B10937501730 $0.000500 $          –  
    B1093572561730 $0.080700 $15,081.22
     ExaDB-D        $25,677.90
    B11062931730 $2.903200 $6,358.01
    B11062721730 $2.903200 $4,238.67
    B1106322561730 $0.080700 $15,081.22
    Difference10%

    In Summary, both ExaDB-XS and ExaDB-D offer the core performance and availability benefits of Exadata within OCI.

    • Choose ExaDB-XS for elasticity, lower entry cost, smaller storage requirement and simplified management on shared infrastructure when physical isolation isn’t the top priority.
    • Choose ExaDB-D for maximum isolation, larger database storage, performance predictability, and control on dedicated hardware, typically for mission-critical, large-scale, or highly regulated workloads.
  • Oracle Database @ Azure Secret to Speed

    Oracle Database @ Azure Secret to Speed

    How “OCI Pods” Bring Sub-Millisecond Latency to Azure

    If you’re running mission-critical apps in the cloud, you know that speed is everything. Traditionally, “multicloud” meant connecting two different clouds over a distance, which always added a delay. Oracle Database@Azure fixes this by physically changing the map.

    Here is how the unique OCI Pod architecture makes sub-millisecond latency possible.


    1. Bringing the Cloud to the “Room Next Door”

    The biggest reason for the speed is physical proximity. Oracle and Microsoft have partnered to build “Child Sites” directly inside Azure data centers. We call these sites OCI Pods.

    Think of an OCI Pod as a physical extension of the Oracle Cloud Infrastructure (OCI). It isn’t a “light” version of the cloud; it contains the exact same hardware and software found in any other OCI region, including:

    • Gen2 Network Stack for ultra-fast data movement.
    • RDMA Networking to power the massive performance of Exadata and Autonomous Database.
    • Off-box Virtualization to ensure your database doesn’t compete for resources.

    2. Direct Local Links: No Detours Allowed

    In a typical setup, data travels through multiple gateways to get from one provider to another. Oracle Database@Azure uses a direct private network link between the OCI Pod and the Azure network in the same building.

    When your Azure app talks to the database, the packets don’t leave the building. They travel through a local link to an edge gateway in the OCI Pod, which hands them directly to your Exadata instance. This “short-circuit” ensures your traffic never leaves the Azure data center, keeping it secure and lightning-fast.

    3. Behind the Scenes: Virtual Mapping

    When you provision an Oracle Database in your Azure VNet, a bit of “cloud magic” happens under the hood:

    • Azure Side: A private IP address is created in your designated Azure subnet.
    • OCI Side: Corresponding Virtual Network Interface Cards (VNICs) are created in a private OCI network.
    • The Link: A virtual mapping is created between the two. Your Azure app thinks it’s talking to a local resource because, for all intents and purposes, it is.

    4. Managed by Oracle, Controlled by You

    Even though the hardware lives in an Azure data center, the OCI Control Plane still manages the show. When you click “Create” in the Azure portal:

    1. Azure sends the request to the Oracle Database@Azure resource provider (hosted in an OCI region).
    2. OCI validates your identity (often using Identity Federation, so you can just use your Azure login).
    3. The OCI Control Plane reaches into the pod inside the Azure data center to build your database.

    Read more: First Principles: Powering mission critical applications with Oracle Database@Azure | cloud-infrastructure

    The Result: High Performance, Zero Friction

    By using the OCI Pod architecture, you get the best of both worlds. You can use Azure’s AI and app services alongside the world’s fastest database, all while enjoying the same security patching, updates, and operational controls used across all of OCI.

    It’s not just two clouds working together—it’s two clouds living together.