Oracle Analytics Cloud licensing in 2026. The OCPU meter bills uptime, not logins.

Oracle Analytics Cloud bills either per user or per OCPU hour, and the OCPU meter charges for every hour an instance is up. In the Oracle Cloud reviews we ran, idle OCPU time cost more than any rate difference.

How is Oracle Analytics Cloud licensed?

Oracle Analytics Cloud (OAC) sells four core SKUs: Professional and Enterprise editions, each available as a hosted named user per month or per OCPU per hour. You choose the metric for each instance when you create it, and that one choice decides the shape of the whole bill for that instance.

Oracle also publishes Bring Your Own License (BYOL) variants of both editions, but only on the OCPU per hour metric. There is no BYOL version of the user metric, so Oracle's billing documentation lists six OAC lines in all. The table below sets out how each part of the model works.

What each edition includes

Both editions include workbooks, datasets, direct connections, data flows, machine learning, the natural language and auto insight features, generative AI assistance and the mobile apps. Enterprise edition adds the capabilities most former OBIEE customers rely on:

• Semantic model. Enterprise semantic modeling, the successor to the OBIEE repository.
• Classic content. Enterprise analyses and dashboards, plus email distribution of them.
• Pixel perfect reporting. Oracle Analytics Publisher, the former BI Publisher.
• Private data sources. Connectivity to databases that are not exposed to the public internet.
• Administration. Usage tracking, customer managed encryption keys and custom knowledge enrichment.

Oracle's own planning guidance says you need the Enterprise Analytics feature set to migrate analyses, dashboards and pixel perfect reports from Oracle BI Enterprise Edition. If you are coming from on premises, the OBIEE and Oracle Analytics licensing guide and the Oracle Analytics Server licensing guide cover the licenses you already hold.

How the OCPU sizes and service limits frame the sizing

A 1 OCPU instance is designated non production, so production OCPU instances start at 2 OCPUs. You can scale between 1 and 16 OCPUs on universal credits. The 24, 36 and 52 OCPU shapes are fixed, and instances created with 10 to 12 OCPUs before August 2024 stay within that range.

Default service limits run 4 OCPUs for Professional and 40 for Enterprise on universal credits, with 200 users for each edition. Pay As You Go and trial tenancies are held at 4 OCPUs whichever edition you pick. The limits are defaults, and you raise them from the Limits, Quotas and Usage page in the OCI Console.

Why does an idle OAC instance cost as much as a busy one?

Because the OCPU meter charges for uptime, and logins never enter the calculation. An instance that sits unused all weekend bills exactly what it bills on a busy Tuesday morning.

Every metric carries an assumption about what the vendor is selling. Per user metrics price access and consumption metrics price work performed, while the OCPU meter prices availability, the capacity to answer a query whether or not anyone asks one. That suits a trading platform far better than a reporting service.

Where the idle hours come from

Consider an analytics service whose users work business hours in two or three time zones. You buy roughly 168 hours of availability a week to serve perhaps 50 hours of real use, and the meter records all 168. That gap between billed hours and used hours is where most of the OAC waste we find comes from.

A worked example: two instances, two schedules

Say you run a 4 OCPU Enterprise instance for production and a 2 OCPU instance for test. The table counts OCPU hours, so the result holds whatever rate your contract carries.

The schedule removes 408 OCPU hours a week, about 40 percent of the bill, or 21,216 OCPU hours over a year. The test instance alone drops by 64 percent, with no change to the contract.

Check the job calendar before you pause production. Scheduled agents, Publisher bursts and data flows that run overnight or at the weekend need the instance to be available. If they do, move the pause window around them.

Why a deeper OCPU rate discount is the wrong first request

The usual advice is to push Oracle for a bigger discount on the OCPU rate, and we would not start there. A discount lowers the price of idle and productive hours alike, so the idle hours stay on the bill. In the example above, Oracle would need to cut the rate by another 40 percent to match a free schedule.

Negotiate the rate after you have cut the hours, when the commitment reflects real use. In most organizations the scheduling conversation belongs to engineering and the rate conversation belongs to procurement, and the two rarely meet. We see the same gap under other consumption meters, from Microsoft Sentinel ingestion to Oracle's OCPUs.

Should you choose the OCPU metric or the user metric?

Choose the metric against the usage pattern of each instance. A small, stable reporting population usually prices best per user. A large or variable population usually prices best per OCPU, and BYOL only strengthens the OCPU case.

How to find your breakeven

To find your own breakeven, divide the monthly OCPU cost by the user month rate from your quote. A month has about 730 hours, so an always on 2 OCPU instance bills 1,460 OCPU hours. Take a hypothetical quote in which one user month costs the same as 20 OCPU hours: the breakeven is 73 users.

Now schedule that instance to 60 hours a week, about 260 hours a month. It bills 520 OCPU hours, and the breakeven falls to 26 users. Scheduling does more than trim the OCPU bill; it shifts the point at which the user metric stops making sense.

How the user brackets limit your flexibility

• Minimum of 10. On universal credits, a user metric instance starts at 10 users.
• Fixed brackets. You can scale only inside a bracket: 10 to 400, 401 to 600, and so on up to 3,000 users.
• New instance to cross. Moving from 300 users to 500, or back, means creating a new instance and migrating content by snapshot.
• Not for BYOL migrations. Oracle's planning guide says the user option is not suitable when you migrate from OBIEE with BYOL.

How the choice differs for a 150 user team and a 3,000 user rollout

A finance team of 150 people who open the same dashboards every week sits comfortably in the first bracket. The user metric gives a flat monthly charge, and there is no uptime to manage. Keep an eye on growth, because crossing 400 users forces a rebuild.

A rollout to 3,000 people across regions and shifts is a different case. Usage is spread across more hours, the user count changes every quarter, and on premises licenses may be available for BYOL. That is the profile the OCPU metric was built for, provided someone owns the sizing and the schedule.

How does BYOL work for Oracle Analytics Cloud?

BYOL allows you to apply on premises analytics licenses you already own to OAC, in exchange for a lower OCPU rate. It is available only on the OCPU metric, so taking it commits that instance to the uptime meter. The rate difference against license included is material, and the entitlements are already paid for.

Oracle's general BYOL to PaaS rules apply: the licenses must stay on active support, and one processor license maps to two OCPUs. Check the OAC entry in the Universal Credits service description for which of your licenses qualify and how Named User Plus counts convert. Our Oracle BYOL guide covers the wider rules.

Where BYOL savings get lost

• Entitlements left on premises. Support keeps being paid on OBIEE or Oracle Analytics Server licenses while the cloud instance runs at the license included rate.
• The wrong metric. An instance built on the user metric cannot take BYOL at all.
• No owner. The license team knows what is on the support contract, the cloud team knows what is deployed, and often no one compares the two lists.

How do universal credits change the OAC bill?

OAC does not bill on its own. It draws from the same universal credit pool as the rest of OCI, at the metered rate per OCPU hour or user month, and credits committed but not consumed by the end of the period are lost.

An idle instance therefore costs you twice. It spends the pool on hours no one used, and the safety margin built into the commitment then expires unconsumed. Neither loss shows on a single invoice. Both appear as soon as you set measured burn against the commitment.

On an uptime meter, the way you operate the instance is worth more than anything you win at the negotiating table.

Contract wording to ask for at renewal

• A commitment sized to measured burn. Base it on the last 6 to 12 months of Cost Analysis data after scheduling, plus migrations you have actually planned.
• A ramp. Step the annual commitment up as workloads move, so year one does not carry capacity you will not reach until year three.
• Rate holds. Fix the discount on the OAC OCPU, user and BYOL lines for the full term, including instances you add later.
• Carry forward of unused credits. Ask for any unconsumed balance to roll into a renewal of equal or larger size, so padding is not simply lost.

The commitment side sits in our OCI negotiation briefing, the OCI cost optimization guide and the comparison of Monthly Universal Credits and annual commitments.

What have we seen in recent Oracle Analytics Cloud reviews?

Across roughly 25 to 35 Oracle Cloud customers we reviewed in 2024 and 2025, the OAC findings repeated regardless of company size. Idle OCPU time, with instances running around the clock for business hours users, outweighed every rate conversation.

The fix in each case was operational before it was commercial, and the negotiation became easier once the numbers showed real need.

How do you check what your OAC instances cost and use?

Start with cost, then compare it with activity. The OCI Console and CLI give you everything needed to put idle hours on one page.

Where to find the numbers

1. Cost Analysis. In Billing and Cost Management, open Cost Analysis and filter Service to ANALYTICS_CLOUD. Group by resource to see each instance.
2. Instance inventory. Use the OCI CLI analytics instance list command for each compartment. The output shows each instance's capacity type and value, license type and feature set.
3. Limits. The Limits, Quotas and Usage page shows the OCPU and user limits for each edition against what you have deployed.
4. Activity. On Enterprise, usage tracking records who ran what and when. Professional does not include usage tracking, so use the sign in reports from your identity domain instead.

Mistakes that cost the most

• Standardizing on Enterprise. Paying the higher edition rate for instances that only run workbooks.
• Sizing for day one. Keeping the partner's go live shape after usage settles.
• Outgrowing a user bracket. Discovering at 401 users that you need a new instance and a snapshot migration.
• Padding the commitment. Adding a safety margin to credits that expire unused.

Scheduling is simple to automate with the OCI CLI analytics instance stop and start commands, or through the Console and REST API. Pausing disables access without restarting the instance, and Oracle presents it as a way to reduce cost. Confirm how your SKU meters a paused instance in the service description before you build the business case.

What will the Oracle account team say, and how should you answer?

Expect a push toward more capacity, the higher edition and a larger commitment. These are the lines we hear most often.

• "Standardize on Enterprise so every team has the full feature set." Show which instances use the semantic model, Publisher or private data sources. The rest can run on Professional.
• "A larger commitment earns a deeper discount." Ask them to price both options, then compare against your measured burn. Credits that expire unused cost the full committed amount whatever the discount, so a ramp usually beats a bigger year one.
• "Leave the instances running so reports are always available." Share the job calendar and pause around it. Oracle's own documentation says pause and resume do not restart the instance, so the risk to content is low.
• "The user metric is simpler to budget." It is, for a stable group under 400 users. Above that, the brackets and the lack of BYOL usually cost more than the simplicity saves.

The wider picture for Oracle customers is in the Oracle knowledge hub.

What to do next

1. Put idle hours on one page. Pull uptime and login data for every instance. That page is the business case for everything that follows.
2. Schedule non production. Pause test and development instances at night and at weekends, the largest single saving on the uptime meter.
3. Resize production. Match OCPU counts to measured concurrency, and review the edition per workload against the 4 and 40 OCPU default limits.
4. Apply BYOL. Inventory on premises analytics entitlements and move qualifying OCPU instances to the BYOL SKU.
5. Check each metric choice. Move small, stable groups to the user metric and growing ones to OCPU before a bracket forces the change.
6. Reset the commitment. Size universal credits to measured burn at the next renewal, so the pool stops financing padding that expires. Our Oracle advisory team can run the review with you.

Frequently asked questions