What is Oracle Analytics Cloud and how is it priced?
Oracle Analytics Cloud, OAC, is the subscription successor to the on premise analytics line. It delivers the same semantic modelling, data visualisation, and enterprise reporting capabilities as OBIEE and Oracle Analytics Server, but as a managed cloud service rather than software you install and run yourself. The shift is commercial as much as technical: OAC replaces the perpetual licence and its per processor minimum with consumption based pricing.
OAC is priced by the OCPU, the Oracle Compute Unit, billed per hour or per month according to the capacity provisioned. This removes two of the sharpest pain points of the perpetual model, the Named User Plus minimum and the fixed processor count, because you pay for the compute you actually run rather than the hardware you happen to own. But it introduces a different discipline, capacity and commitment management, which is where the new risks live. This is the cloud chapter of the broader Oracle BI and analytics licensing story.
Universal Credits and OCPU consumption
OAC consumption is purchased through Universal Credits, Oracle's pooled cloud commitment mechanism. A customer commits to a quantity of credits, typically annually, drawn down as services consume OCPU hours. The model is flexible in that credits can be applied across eligible OCI services, but it is a commitment, and the commitment is where buyers lose money.
The mechanics matter. Credits are consumed as capacity runs, so an OAC environment left provisioned around the clock consumes far more than one scaled down outside business hours. Understanding the consumption profile of the actual workload, when it runs, how much capacity it genuinely needs, and whether it can be scaled or paused, is the foundation of sizing the commitment correctly. The same Universal Credits dynamics govern the wider OCI estate.
Bring Your Own Licence from OBIEE and OAS
Customers with existing OBIEE or Oracle Analytics Server entitlements can apply them toward OAC consumption under Bring Your Own Licence. BYOL reduces the per OCPU rate substantially compared with the licence included rate, recognising that the customer has already paid for the underlying software. But eligibility and the conversion ratio depend on the existing metric and an active support contract.
BYOL is only a saving if the perpetual licence you are bringing would otherwise sit idle. If it is still doing useful work on premise, you may be paying for the same capability twice.
The economic test is whether the perpetual entitlement being brought would otherwise be stranded. Bringing a licence that is still running a productive on premise workload can mean paying for that capability twice. The right analysis models the on premise and cloud positions together, exactly the discipline set out in the BYOL economics guide, and treats the perpetual licence as an asset to be deployed where it yields the most value.
Commitment shaping and the unused capacity trap
The signature OAC mistake is oversizing the Universal Credits commitment. Oracle's discounting rewards larger commitments, which creates pressure to commit to more capacity than the workload will consume in order to secure a better unit rate. The result is a familiar trap: a large discount applied to capacity that is never used, producing a higher effective cost than a smaller, well utilised commitment would have.
| Approach | Discount | Utilisation risk | Net outcome |
|---|---|---|---|
| Oversized commitment | High unit discount | Pay for unused capacity | Often higher effective cost |
| Right sized commitment | Moderate discount | Matched to consumption | Lowest effective cost |
| Undersized commitment | Low discount | On demand overage rates | Higher marginal cost |
The optimum is a commitment sized to genuine forecast consumption with modest headroom, not to the discount tier. Reaching it requires an honest consumption forecast built from the workload profile rather than from the discount schedule, and the discipline to resist a larger commitment that looks cheaper per unit but costs more in total.
When does cloud beat on premise OAS?
The decision between OAC and on premise Oracle Analytics Server is genuinely workload dependent, and defaulting to either is a mistake. A stable, predictable analytics workload running on already owned, fully supported hardware can be cheaper on premise, because the perpetual licence and the hardware are sunk costs and the marginal cost of running is low. A variable, seasonal, or rapidly growing workload can be cheaper in the cloud, because consumption pricing matches cost to use and avoids provisioning for peak.
The honest analysis models both over a multi year horizon, accounting for support costs, hardware refresh, the BYOL position, and the realistic consumption profile. It is the same structured comparison our BI and analytics advisory runs, and it frequently overturns the assumption, in both directions, that one model is obviously cheaper.
OAC editions, feature tiers and OCPU sizing
Oracle Analytics Cloud is not a single SKU but a set of editions and capacity choices, and the combination determines the cost. The edition governs which capabilities are available, and the OCPU count governs how much compute is provisioned. Both decisions interact, because a higher edition on more OCPUs consumes Universal Credits faster, and an environment sized for peak but run continuously consumes far more than one scaled to its actual usage pattern.
OCPU sizing is the lever buyers most often get wrong. Provisioning generously to guarantee performance, then leaving the environment running around the clock, is the most expensive way to operate OAC, because consumption accrues whether or not anyone is using the service. An environment that scales down outside business hours, or that pauses non production instances overnight and at weekends, can consume a fraction of the credits of an always on equivalent while delivering the same business hours performance. Building the consumption forecast from the real usage pattern, rather than from a peak sizing held constant, is the foundation of a sensible commitment.
The edition choice should be driven by the capabilities actually used, not by the most complete tier on offer. Paying for a higher edition to access features that a minority of users need is a common overspend, and it is often cheaper to provision the broad community on a lower edition and handle specialist needs separately. The analysis is the same disciplined matching of entitlement to need that governs the on premise OBIEE metric decision.
A worked OAC versus OAS cost model
The cloud versus on premise decision is best resolved with a multi year model rather than a single year snapshot, because the cost structures differ in shape. On premise Oracle Analytics Server front loads cost into perpetual licences and hardware, then carries an annual support stream; Oracle Analytics Cloud spreads cost evenly as a recurring subscription or consumption charge. Comparing them fairly means projecting both over the same horizon.
| Cost element | On premise OAS | OAC subscription |
|---|---|---|
| Year 1 | High (licence + hardware) | Moderate (subscription) |
| Years 2 to 3 | Low (support only) | Moderate (recurring) |
| BYOL effect | Asset already owned | Reduces OCPU rate if applied |
| Scaling flexibility | Fixed to hardware | Scales with consumption |
For an estate that already owns perpetual OAS licences with paid up support, the marginal cost of continuing on premise is often just the support stream, which can be lower than an equivalent cloud subscription over a three year horizon. For an estate facing a hardware refresh, a costly upgrade, or unpredictable growth, the cloud's flexibility and avoided capital cost can win. The BYOL position tilts the comparison: applying owned licences to OAC reduces the OCPU rate and can make the cloud competitive even where it would not be at the licence included rate.
There is no universal answer to cloud versus on premise. There is only the arithmetic for your workload, and the discipline to run it before the sales conversation runs it for you.
The honest conclusion is that the decision is estate specific and must be modelled, not assumed. A buyer who builds the multi year model, accounts for the BYOL effect, and sizes the commitment to genuine consumption will reach the right answer for its workload; a buyer who defaults to the cloud under sales pressure frequently strands perpetual value and oversizes the commitment. Running that model is a standard part of our analytics advisory and the broader cloud and OCI practice.
Governing OAC consumption and cost
Where the on premise model fixes cost at purchase, Oracle Analytics Cloud makes cost a function of ongoing behaviour, which means cost control becomes a governance discipline that runs for the life of the service. Universal Credits are consumed as capacity runs, so the levers that matter are the ones that govern how much capacity runs and for how long: the OCPU count provisioned, the schedule on which environments run, and the edition each environment uses. An OAC estate left provisioned at peak capacity around the clock will consume credits at several times the rate of one scaled to its actual usage pattern.
Effective governance starts with monitoring. Oracle provides consumption visibility, and a buyer who watches OCPU consumption against the Universal Credits commitment can spot the drift, an environment that was scaled up for a project and never scaled back, a non production instance running at weekends, an edition higher than the workload needs, that quietly erodes the commitment. Acting on that visibility, by scaling environments to demand, pausing non production outside business hours, and matching editions to need, is what keeps consumption aligned with the forecast that sized the commitment.
The discipline matters most around the commitment renewal. A commitment sized from a clear, monitored consumption history can be right sized with confidence, whereas one renewed on the basis of an unmonitored estate is renewed blind, usually upward, because the safe assumption in the absence of data is to commit to more. Governing consumption through the term is therefore not only a cost control in itself but the foundation of a defensible renewal, the same forward looking discipline our cloud and OCI practice applies across the OCI estate.
Planning an OBIEE to OAC migration
A migration from on premise OBIEE or Oracle Analytics Server to Oracle Analytics Cloud is as much a commercial exercise as a technical one, and the order in which the questions are answered determines the outcome. The first question is the BYOL position: whether existing entitlements can be applied to reduce the OCPU rate, and whether doing so strands perpetual value that is still productive on premise. The second is the consumption forecast: what the workload will actually consume in the cloud, built from the real usage pattern rather than from the on premise peak.
The cheapest OAC migration is the one modelled before it starts. The most expensive is the one that strands perpetual value and oversizes the commitment to win a discount.
Only with those two answers can the commitment be sized correctly and the cloud versus on premise decision be made on arithmetic rather than on the direction of the sales conversation. A migration that proceeds without modelling the BYOL effect and the consumption forecast typically strands owned licences and oversizes the Universal Credits commitment, producing a cloud bill higher than the on premise cost it replaced. The disciplined path, modelling both positions over a multi year horizon before committing, is the one our analytics advisory follows, and it draws on the broader BYOL economics that govern every Oracle cloud decision.
Oracle Analytics Cloud licensing: a closing summary
Oracle Analytics Cloud licensing trades the per processor minimum of the perpetual model for a different discipline: commitment and consumption management that runs for the life of the service. The model can be the cheaper, more flexible option, but only when the Universal Credits commitment is sized to genuine forecast consumption rather than to the discount tier, and when the BYOL position is modelled rather than assumed. Oversizing the commitment to win a larger discount is the signature mistake, producing a high discount applied to capacity that is never used.
Cost becomes a function of behaviour, so governance matters throughout the term. Monitoring OCPU consumption against the commitment surfaces the drift, an environment scaled up and never scaled back, a non production instance running at weekends, an edition higher than the workload needs, that quietly erodes the commitment, and acting on that visibility keeps consumption aligned with the forecast. A monitored history is also the foundation of a defensible renewal, because a commitment renewed on data can be right sized with confidence.
The cloud versus on premise decision itself should be made on a multi year model rather than defaulted in either direction. A fully supported perpetual estate can be cheaper to run, while a variable or growing workload can favour the cloud, and the BYOL effect can tilt the comparison. A buyer who forecasts consumption honestly, sizes the commitment to it, governs consumption through the term, and models both paths before committing will get the benefits of the cloud model without its traps.
The buyer side view
Oracle Analytics Cloud trades the per processor minimum for commitment risk. It can be the cheaper, more flexible model, but only when the commitment is sized to real consumption, the BYOL position is modelled rather than assumed, and the cloud versus on premise decision is made on arithmetic rather than on the direction of the sales conversation. The buyer who forecasts consumption honestly, right sizes the commitment, and deploys perpetual licences where they yield the most value will get the benefits of the cloud model without its traps. Start from the BI and analytics pillar and the BYOL economics guide, then model your own workload before you commit.
Oracle Analytics Cloud licensing: frequently asked questions
How is Oracle Analytics Cloud priced?
OAC is priced by OCPU, the Oracle Compute Unit, billed by the hour or month and drawn from a Universal Credits commitment. There is no perpetual licence and no per processor minimum, but the commitment must be sized carefully to avoid paying for capacity you do not consume.
Can I use my OBIEE licences on OAC?
Oracle Analytics Cloud supports Bring Your Own Licence from eligible OBIEE and Oracle Analytics Server entitlements with active support. The conversion ratio and eligibility depend on your existing metric, so model whether BYOL or a fresh subscription is cheaper before committing. See the BYOL economics guide.
Is OAC cheaper than on premise OAS?
It depends on the workload. A stable, fully supported perpetual OAS estate can be cheaper to run, while a variable or seasonal workload can favour consumption based cloud pricing. The decision should be modelled, not defaulted to the cloud.
What is commitment shaping?
Commitment shaping is the practice of sizing a Universal Credits commitment to balance discount against utilisation. Oversizing to win a larger discount can leave you paying for unused capacity, while undersizing exposes you to higher on demand rates. Our cloud advisory models the optimum.
Related analysis in this cluster: Oracle Essbase Cloud licensing.