Oracle Analytics Cloud is a subscription, billed by the OCPU hour or by the named user month, in Professional or Enterprise edition. The meter runs on uptime, and the sizing band you pick at provisioning is harder to change than the rate.
Oracle Analytics Cloud is a subscription, not a license. It bills either by OCPU per hour or by hosted named user per month, in Professional or Enterprise edition, and the meter runs on uptime rather than logins. The sizing bands you choose at provisioning time are harder to change than the rate.
Both metrics exist and you choose one per instance, not per person. The choice is made at provisioning and is not a switch you flip later. Getting it wrong means rebuilding the instance, so treat it as an architecture decision rather than a procurement one.
The OCPU metric charges for each Oracle Compute Unit for every hour the instance is running, drawn down from universal credits. Consumption is independent of how many people log in. It is the right metric when the audience is unbounded, embedded in another application, or seasonal.
The user metric charges per provisioned user per month regardless of activity, with a floor of ten users. Oracle's published entry rate is $162.30 a month for ten Professional users. It suits a small, stable, nameable analyst team and nothing else.
Verify the current rates and SKU names against the Oracle Cloud price list before you model anything. Oracle changes cloud rates without a price list amendment cycle, unlike the technology price list.
Enterprise if you need a governed semantic model, pixel accurate reports or private data sources, and Professional for everything else. The two editions are not tiers of speed. They are a feature boundary, and Oracle draws it in the Oracle Analytics Cloud editions documentation.
Where the OAC edition line falls
| Capability | Professional | Enterprise |
|---|---|---|
| Workbooks, visualizations, self service datasets | Yes | Yes |
| Data flows, machine learning, natural language and generative AI assistance | Yes | Yes |
| Enterprise semantic modeling | No | Yes |
| Oracle Analytics Publisher, pixel accurate reporting | No | Yes |
| Connectivity to private data sources | No | Yes |
| Email distribution of dashboards and reports | No | Yes |
| Usage tracking and customer managed encryption keys | No | Yes |
Edition is a property of the instance, not of the user. If forty modelers need Enterprise and eight hundred consumers only view workbooks, buying Enterprise for all 840 is the default outcome and it is expensive. Two instances, one per edition, is often the cheaper design.
Oracle Analytics Server is the perpetual on premises build of the same lineage, licensed by Processor at $221,250 or Named User Plus at $2,000. Steady workloads with a fixed user population sometimes cost less there. The full comparison and the migration decision sit in our Oracle Analytics Server licensing guide.
They matter because they are decided at provisioning and several of them cannot be changed in place. OAC does not scale smoothly. It scales in defined steps, and one of those steps requires you to build a new instance and migrate every workbook, dataset and permission across.
OAC sizing mechanics you should know before provisioning
| Dimension | What Oracle allows | What it costs you to get wrong |
|---|---|---|
| OCPU shapes | 1 to 16 flexible, then fixed 24, 36 and 52 | A jump from 16 to 24 is a 50 percent step in spend |
| Smallest shape | 1 OCPU, non production only | Production floors at 2 OCPUs |
| User bands | 10 to 400, 401 to 600, 601 to 900, 901 to 1400, 1401 to 2200, 2201 to 3000 | Growing from 300 to 500 users needs a new instance and a content migration |
| Default service limits | 4 OCPUs Professional, 40 OCPUs Enterprise, 200 users per instance | A go live can stall on a limit increase request |
| Scaling downtime | No outage, but around 60 minutes of degraded performance | Scaling during month end reporting is a self inflicted incident |
Source: Oracle Analytics Cloud administration documentation, scaling and service limits sections.
Instances built before August 2024 on 10 or 12 OCPUs can only scale inside that old range. Reaching the current 1 to 16 flexible range means creating a new instance and migrating. Several estates we reviewed were paying for 12 OCPUs because moving to 8 was not offered on the shape they were provisioned on.
Pick the user band with 18 months of growth in mind, because the cost of crossing one is a project, not an invoice line. The same applies to OCPU shapes above 16. Ask Oracle in writing, before signing, what the migration path is between bands.
White Paper · Oracle Analytics
OAC vs OAS, and the door that doesn't reopen. Read it free.
Yes, but only on the OCPU SKUs, and only while the on premises support stream stays alive. Oracle publishes Professional and Enterprise BYOL variants priced per OCPU per hour, alongside the license included variants. There is no BYOL option on the user per month metric, which quietly forces the metric choice for anyone with existing entitlements.
The failure mode is double running. If the on premises deployment stays live for a transition period, you are consuming the entitlement twice and the BYOL claim is weak. Set a dated decommission plan for the source system and evidence it, because Oracle will ask what happened to the old servers.
The support trap in one sentence. The moment you terminate on premises support to save the 22 percent, the BYOL rate stops being available to you, and the cloud bill steps up to license included at the next renewal with no negotiation attached.
Whether to move at all, and in what order, is the on premises decision. We set out the OBIEE to OAS to OAC sequence, including how to keep the door open, in the Oracle Analytics Server guide. Read that before you commit to a migration date.
Because the OCPU meter charges for uptime, not usage, and nobody owns uptime. An instance running at three in the morning bills exactly the same as one carrying a board pack. In most estates this single mechanic is worth more than any rate negotiation.
Development, test and training instances rarely need to run overnight or at weekends. A schedule that runs them twelve hours a day, five days a week removes roughly 64 percent of their hours. That is a configuration change, not a contract change.
Instances get sized for a quarter end peak and then pay that peak every hour for the rest of the year. Size for the normal week and scale up deliberately for the peak, accepting the hour of degraded performance. Put the scale up and scale down in the month end runbook so it actually happens.
On the user metric, a provisioned account bills whether or not it is used. Leavers, contractors and duplicate accounts survive for years because nobody owns the list. A quarterly reconciliation against the HR leaver feed is the cheapest saving available on this product.
The common advice is to buy a generous annual universal credits commitment up front to lock in the best discount rate. We disagree. In roughly 6 out of 10 OAC estates we reviewed, the committed pool was larger than real consumption, so the discount was applied to credits that expired unused, which is a worse outcome than a smaller commit at a slightly higher rate. The buyer side move is to instrument actual OCPU hours for a full quarter first, apply stop schedules and right sizing, and only then size the commitment to measured demand plus a modest buffer. A discount on credits you never burn is not a saving.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
The OAC meter does not care whether anyone logs in. It cares whether the instance is running. Fix uptime before you negotiate the rate.
OAC draws down from the same universal credits pool as every other OCI service, which is exactly why analytics overspend is hard to see. There is no separate analytics invoice. The instance simply burns credits that were budgeted for something else, and the problem surfaces at the annual true up.
An annual commitment buys credits at a negotiated rate for a fixed term, and whatever is unused at the end of the term is gone. Consumption beyond the commitment bills at standard rates, without the discount. That asymmetry is the reason a conservative commitment normally beats an ambitious one.
Bring one figure to the renewal: your measured OCPU hours per month for the last twelve months, per instance, with the stop schedules already applied. Everything else in the conversation is a forecast. A measured baseline is the only thing that survives contact with an account team.
It does not include your data platform, your integration tooling, or any right to run software outside the service. This is where cloud buyers repeat the on premises mistake in a new form: assuming that because a capability appears in a demo, it is inside the subscription they signed.
Both options exist and you pick one per instance: OCPU per hour or hosted named user per month. OCPU suits large, spiky or embedded audiences because consumption is independent of logins. Named user suits small fixed analyst teams and carries a floor of ten users.
Oracle's published entry point is $162.30 a month for ten Professional named users. Ten is a floor rather than a starting suggestion, so there is no smaller user based configuration. On the OCPU metric the practical floor is a 1 OCPU instance, which Oracle designates as non production.
No. Edition is a property of the instance, so every user on it consumes the same edition. Where a small modeling team needs Enterprise and a large consumer population does not, two instances is usually cheaper than upgrading everyone.
Not in place. Oracle provisions user based instances inside fixed bands and 300 and 500 sit in different bands, so the change requires a new instance and a content migration. Choose the band with eighteen months of growth in mind.
No. Oracle publishes BYOL variants of Professional and Enterprise on the OCPU per hour metric only. Holding on premises analytics entitlements therefore pushes you toward the OCPU metric whether or not your user population would have suited it.
The BYOL rate depends on holding supported licenses, so cancelling support removes the basis for it. Expect the subscription to move to license included pricing at the next renewal. Never terminate on premises support as the first step of a cloud migration.
The OCPU meter charges for uptime, not logins, so an idle instance bills at full rate. The most common cause is a non production instance running around the clock. Stop schedules and honest right sizing usually recover more than any rate negotiation.
Yes. A provisioned account bills every month regardless of activity, so leavers and duplicates keep consuming the metric until someone removes them. Reconcile the user list against the HR leaver feed quarterly and assign a named owner.
No. OAC is a cloud subscription with Professional and Enterprise editions, sold by OCPU hour or user month. OAS is perpetual on premises software on the Technology Price List, sold by Processor or Named User Plus. They share a heritage and some model formats, not a license or a price book.
Not before measuring consumption for a full quarter. A discount on credits that expire unused is worse than a smaller commitment at a slightly higher rate. Instrument first, fix uptime second, and size the commitment third.
Oracle Analytics is sold two ways, a perpetual per processor server and a per OCPU cloud subscription, and the move between them does not reverse. The prices and the five year model.
Used across more than five hundred enterprise engagements. Independent. Buyer side. Built for procurement leaders running the next renewal cycle.
