How can organizations prevent storage requirements from driving unnecessary Oracle infrastructure costs?
For many enterprises, Oracle Database is one of the largest recurring investments in the IT budget. The cost does not stop with cloud compute and storage. Oracle Database licenses and annual support can dominate the long-term economics of a deployment.
Yet customers can spend more than the workload requires when storage performance and VM size are tightly coupled. As an Oracle database needs more IOPS or throughput, an attached-disk architecture may require a larger VM to unlock those storage limits, even when the database does not need the additional CPU capacity.
The problem? Bigger VMs can mean higher Oracle costs.
Oracle licenses in authorized public cloud environments are calculated from the maximum vCPU count of the selected instance type. For Google Cloud Platform, Oracle states that when multithreading is enabled, two vCPUs are counted as one Oracle Processor license. If multithreading is not enabled, one vCPU is counted as one Oracle Processor license. Therefore, moving to a larger VM can increase the Oracle Database license requirement as well as the associated annual support cost.
In simple terms, if a company doubles a multithreaded Google Cloud VM from 24 vCPUs to 48 vCPUs, the Oracle Processor license count used for this policy calculation increases from 12 to 24. The customer can end up licensing twice as many Oracle processors, even when the VM was enlarged only to obtain more storage performance.
Customer takeaway Customers may be paying Oracle licensing and support costs for storage performance they need, rather than for compute capacity the database actually uses. |
|---|
The cost impact of storage-driven compute sizing
A production Oracle database may need high IOPS, high throughput, and consistently low latency. With traditional VM-attached storage, the shortest route to those storage targets can be a larger compute instance. That creates a chain reaction:
- The VM costs more each month.
- The Oracle Processor license requirement can increase with the VM vCPU count.
- Annual Oracle support increases with the licensed software footprint.
- Much of the added CPU capacity may remain unused because storage, not database processing, drove the upgrade.
This creates an infrastructure cost effect: storage constraints influence compute sizing, and compute sizing can influence Oracle licensing economics.
A different approach: decouple storage performance from compute
Google Cloud NetApp Volumes (GCNV) allows storage capacity and performance to scale independently from the database VM. Organizations can size the Oracle server for the CPU and memory the database actually needs, then configure storage for the capacity, IOPS, and throughput the workload requires.
This separation helps customers:
- Right-size Oracle database VMs around application demand.
- Avoid adding vCPUs only to reach an attached-disk performance limit.
- Reduce the Oracle-licensed processor footprint where a smaller VM is sufficient.
- Adjust storage capacity and performance without tying every change to a VM resize.
- Align infrastructure spend more closely with workload requirements.
The goal is not to make storage cheaper in isolation. The goal is to prevent storage requirements from making the entire Oracle stack more expensive.
Modeled TCO: up to 30% lower
NetApp modeled self-managed Oracle Database Enterprise Edition on Google Compute Engine using two storage approaches: Hyperdisk Balanced and Google Cloud NetApp Volumes. The model includes Google Compute Engine, Oracle Database licenses and support, and storage over a three-year term.
Example: a high-throughput Oracle Enterprise Edition workload
The largest modeled workload requires 50 TiB of capacity, 160,000 IOPS, and 5,120 MiB/s of throughput. In the model, the GCNV design uses a 24-vCPU VM, while the Hyperdisk Balanced design uses a 48-vCPU VM to satisfy the workload assumptions.
Modeled metric | Hyperdisk Balanced | GCNV |
|---|
VM size | 48 vCPU | 24 vCPU |
Oracle Processor licenses* | 24 | 12 |
Monthly TCO | $59,657 | $43,488 |
Three-year TCO | $2,147,641 | $1,565,566 |
Three-year savings | - | $582,075 |
TCO reduction | - | 27.1% |
*Illustrative processor count follows Oracle's stated Google Cloud rule for multithreaded processor cores: two vCPUs equal one Oracle Processor license. The TCO values come from the supplied NetApp model.
What drives the savings? The model does not assume that GCNV storage is always less expensive than attached disks. The economic advantage comes from using fewer vCPUs in the GCNV configuration and therefore lowering compute, Oracle Database licensing, and support costs enough to offset the storage cost difference. |
|---|
Performance demonstrated in the tested configurations
The SLOB performance data used in the model demonstrate that GCNV iSCSI can deliver approximately 159,000 total IOPS in the tested configurations. The selected 8-vCPU 100% read test recorded approximately 158,877 IOPS at 0.385 ms latency, while the 8-vCPU 90/10 read/write test recorded approximately 158,872 IOPS at 0.424 ms latency.
These results illustrate the architectural point: storage performance can be delivered without forcing VM sizing to follow an attached-disk scaling curve. Customers should still validate their own Oracle workload mix, block sizes, queue depth, latency objectives, and availability design before final sizing.
Additional value beyond infrastructure TCO
Faster application-consistent recovery
Application-consistent snapshots, consistency groups for Oracle ASM, and Oracle recovery workflows can help accelerate restoration and point-in-time recovery.
Rapid Dev/Test and patch validation
Space-efficient thin clones can create writable database copies without first duplicating all physical data blocks, helping teams provision environments for patch validation, development, testing, reporting, and analytics.
Resilient HA and disaster recovery designs
GCNV storage replication can be combined with Oracle Data Guard as part of a layered availability and disaster recovery architecture. Recovery objectives depend on the selected design and customer workload, so they should be validated for each deployment.
How to evaluate your own Oracle opportunity
Start with a simple question:
How much of our Oracle VM size is driven by database CPU and memory demand, and how much is driven by attached-storage limits?
A practical assessment should compare:
- Observed database CPU and memory utilization.
- Required steady-state and peak IOPS, throughput, and latency.
- The smallest VM that satisfies compute demand.
- The VM size required by each storage option.
- Oracle edition, license metric, existing entitlements, annual support, and contract terms.
- Storage capacity, performance, protection, replication, backup, and growth requirements.
- Three-year compute, license, support, storage, and operational costs.
Reduce storage-driven Oracle infrastructure overprovisioning
Oracle cloud economics are often treated as a compute-pricing or contract-negotiation exercise. Storage architecture belongs in that conversation because it can determine the VM size and, in turn, the Oracle licensing footprint.
Google Cloud NetApp Volumes changes the equation by allowing storage performance and compute to scale independently. In NetApp’s modeled scenarios, this architecture reduced three-year Oracle TCO by up-to-30% cost-reduction message for customer conversations. Actual results depend on workload requirements, configuration, licensing terms, and pricing.
The opportunity is not to reduce Oracle licensing arbitrarily, but to align compute resources with actual database demand. By independently scaling storage performance, organizations can avoid storage-driven VM overprovisioning and potentially reduce the associated Oracle licensing and support footprint.
Get started
Evaluate your Oracle workload using actual CPU utilization, storage-performance demand, licensing terms, and recovery requirements. A workload-specific assessment can identify whether storage-driven VM overprovisioning is increasing your Oracle total cost of ownership.
Contact NetApp to discuss Oracle on Google Cloud NetApp Volumes
