Oracle PULA vs ULA compared. Which unlimited agreement costs less over ten years.

A PULA and a ULA grant the same unlimited use of the same named programs. Only the ULA ends in a certification that can bring support down, if the order allows it, so your deployment trajectory decides which costs less.

What is the difference between an Oracle PULA and a ULA?

Both give you unlimited deployment of the same named Oracle programs. A ULA runs for a defined period, commonly three years, and ends with a certification that fixes a number of perpetual licenses. A PULA, the Perpetual Unlimited License Agreement, never expires and never certifies.

The perpetual term drives every other difference. The two agreements separate on term, certification, support and audit, and support decides the lifetime bill far more than the signing fee does.

What do both agreements have in common?

The contract documents look almost identical. Read these parts first, because they set the limits of the unlimited right:

• The named programs. The exact list of programs and options you may deploy without limit. Anything not on it is licensed the normal way.
• The customer definition. The legal entities allowed to use the programs. Subsidiaries left off the schedule, and companies you buy later, sit outside the right unless the order says otherwise.
• The territory and the deployment rules. Where the programs may run, and whether public cloud deployments count.
• The fee and the support fee. The license fee is paid once. The annual support fee is the number you will live with.

Neither agreement covers anything outside that named scope. Unnamed options, adjacent products and entities outside the schedule are ordinary audit exposure on either route.

What happens at ULA certification, and why does a PULA have no equivalent?

Certification converts unlimited use into a fixed perpetual entitlement, the most consequential event in a ULA. You measure deployment of the named programs, declare it in a certificate signed by an officer of your company, and Oracle converts that count into perpetual licenses. The number becomes your support base from then on.

The count follows Oracle's normal processor rules, including the core factor table for physical servers. Four habits separate a clean certification from a hurried one:

• Measure early. Start the count two years before expiry. A count begun in the final quarter is a hurried one.
• Certify on production reality. Count what runs in production, as set out in the counting standard. A count taken at peak deployment or built on a partitioning assumption is one Oracle will challenge.
• Document everything. Keep the evidence Oracle will ask to see before it asks for it: host inventories, core counts, and the date each server was deployed.
• Take care with virtualized servers. Oracle's processor and core rules decide how much of a VMware cluster you are deemed to run, and a virtualized database can count every host the cluster could move it to.

A PULA never certifies. With no moment to lock a number or reset support, the deal you sign is the deal you keep paying, which is why its entry terms carry far more weight.

How do you check your own deployment before certifying?

Run the sources Oracle's auditors use before they do. The DBA_FEATURE_USAGE_STATISTICS view shows which database options and packs have been used, and our note on the feature usage report explains how to read it. Pull host and core data from vCenter or your hypervisor console.

Then reconcile both against the CMDB and treat every gap as a finding. A server vCenter knows about and the CMDB does not can undermine a certificate. Our ULA certification guide covers the full sequence.

How does Oracle support differ between a ULA and a PULA over ten years?

Support produces the lifetime difference. Oracle prices it at 22 percent of the net license fee each year, so over ten years it comes to more than twice the signing fee. A PULA never reviews that stream. A ULA certification gives you discrete licenses per program, and a chance to stop paying for programs you do not run.

Why does the support reset need to be written in at signing?

Oracle's Software Technical Support Policies work against partial reductions. Three rules in them matter here:

• License sets. All licenses of a program form a license set, and every license in a set must be supported at the same level.
• Repricing. If a subset of licenses on a single order is terminated, support on the rest of that order is repriced at Oracle's list support price less the standard discount.
• Cap and floor. The new fee cannot exceed what you paid before, plus annual adjustments, and cannot fall below what you already pay for the licenses you keep.

Certified ULA licenses usually sit on one order, and the unlimited fee was never priced per program. Without contract wording, the saving from dropping an unused option can be repriced back onto the programs you keep. Negotiate the reset into the ULA order before you sign.

What does a ten year comparison look like in practice?

Say a company is offered a ULA at $5,000,000 or a PULA at $6,000,000 for the same programs, with support at 22 percent of each fee, held flat. In the stable case, certification at year 3 shows two named options unused, and the order allows you to drop their support, 20 percent of the annual bill, from year 4.

In the growing case, the ULA is renewed at years 4 and 7, and the third term certifies at the end of year 9. Each renewal fee is $1,800,000.

On a stable footprint the ULA costs $4,740,000 less, about 25 percent below the PULA. If deployment keeps growing and each renewal adds 22 percent of its fee to support, the PULA wins by $4,756,000, about 20 percent below the ULA total. Annual support increases widen both gaps.

Does a PULA or a ULA protect you in an Oracle audit?

Both protect the named programs inside the agreed scope and nothing beyond it. Programs not named, options not listed and entities not covered are normal exposure under either agreement, and a review probes those edges first.

A PULA lowers routine measurement friction on the named programs, because there is no certification to defend. A ULA concentrates attention on the certification event, where the count is fixed and both sides know it matters.

Where does an Oracle review look first?

1. Options outside the list. A ULA naming Database Enterprise Edition does not cover the Diagnostics Pack or Partitioning unless they are named too.
2. Entities outside the customer definition. Acquired companies and joint ventures often deploy the programs before anyone checks the schedule.
3. Adjacent products. WebLogic or Oracle middleware running next to a database covered by the agreement is licensed separately.
4. Cloud deployments. Workloads moved to AWS or Azure are counted under a different policy, and the agreement may or may not include them.

How does public cloud change the count?

Both agreements raise cloud counting questions as workloads move to authorized cloud environments. Oracle counts vCPUs there under its authorized cloud environment policy, and many unlimited agreements restrict whether those deployments count toward the right. Confirm in writing whether cloud deployments count before you sign either agreement.

How do you choose between a PULA and a ULA?

Choose by deployment trajectory. Build a ten year model for both from your own capacity plan. In roughly 6 of 10 comparisons we have run with both models properly priced, trajectory decided the outcome, and the ULA won clearly whenever the footprint was stable or heading to cloud.

Why we disagree with calling the PULA the safe premium choice

The standard line is that a perpetual agreement is the premium, worry free option and a ULA is the budget choice you will regret at renewal. We disagree. A PULA does remove certification work, which is tedious, but that same work is what allows a ULA holder to cut support.

Buyers hear that they are avoiding an obligation. In practice they are giving up the one reset the agreement offers, in exchange for convenience. Treat the PULA as the right answer only when a funded growth plan supports it.

Declining certification means declining the only scheduled moment when your Oracle support base can go down.

Why do the two models diverge after year five?

The models separate most in years six through ten, a window vendor proposals rarely chart and buyers rarely model. In the first three to five years the perpetual route often looks cheaper, because a growing footprint is consuming a right already paid for.

After that, the price stays put and the footprint changes. Deployment flattens, applications are retired, workloads move, and the annuity keeps compounding against a footprint that has stopped expanding.

Cloud migration sharpens the divergence. A perpetual on premises unlimited right becomes a stranded cost the moment workloads leave. A ULA allows you to certify a smaller production footprint and reduce support as the data center shrinks.

How does the answer change with your situation?

The practical test is one question: will your footprint on these specific named programs still be growing in year eight? Answer it from funded plans only.

• Still growing in year eight, with budget behind it. The perpetual agreement may be the cheaper instrument, because repeated ULA fees and the support they add cost more than one perpetual fee.
• Stable, or growing only to year three or four. The ULA and its reset are worth more than the discount you are offered to give it up.
• Moving to a public cloud or a SaaS replacement. The ULA is usually the better choice, provided the cloud counting and certification terms are settled at signing.
• Unable to answer. Treat it as a no. Uncertainty favors the agreement that has an exit point.

The ten year price of that choice is worked through in the PULA versus ULA pillar, the instrument itself on the Oracle PULA page, and the exit route in the exit playbook.

What have we seen in recent PULA and ULA negotiations?

Across roughly 30 to 40 deals in 2024 and 2025 where both unlimited models were on the table, the outcome split by trajectory. On stable footprints, a ULA with a disciplined certification beat the perpetual model by 20 to 35 percent over ten years, almost entirely through the support reset.

Where deployment kept compounding, the perpetual model saved 12 to 22 percent of lifetime cost against repeated ULA cycles and fees. In 6 in 10 of these deals, Oracle proposed the model that favored its own support annuity. The same mistakes came up again and again:

• Comparing on the signing fee. The fee is the smallest part of a ten year bill.
• Taking the trajectory from ambition. Growth plans without budgets behind them made the PULA look better than it was.
• Leaving the support reset out of the model. Without it, the ULA's main source of value disappears from the comparison.

Buyers chose correctly only where an independent lifetime model was built before responding to Oracle. The wider library sits in the Oracle practice.

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

Expect the pitch to lean on comfort and deadlines. These are the lines we hear most, with replies that keep the talk on lifetime cost.

What contract terms should you ask for in a PULA or a ULA?

Ask for terms that protect the reset in a ULA and create an exit in a PULA, then settle scope in both. Each of these is far easier to win before signature than at any later point.

Terms for either agreement

• Named programs, spelled out. Every program and option by its price list name, so scope cannot be argued later.
• Customer definition with acquisitions. Current entities by name, plus a rule for companies you buy and a right to carry licenses with a divested business.
• Cloud counting. Which clouds count, how processors are counted there, and whether those deployments count toward the right.
• A cap on annual support increases. Escalation is the line that compounds for ten years.

Terms specific to each agreement

• ULA: support reduction after certification. The right to drop support on named options with no certified deployment, without repricing the programs you keep.
• ULA: certification mechanics. The measurement method, the treatment of virtualized and cloud servers, and the evidence Oracle may request.
• PULA: a defined conversion path. A right to certify out at a date you choose, because there will be no natural moment later. The PULA contract traps guide covers the wording in detail.

What to do next

1. Write a ten year deployment trajectory. Cover the named Oracle programs, and source it from the capacity plan rather than the proposal.
2. Price both models across the full horizon. Include support escalation, and label your footprint growing, stable or cloud bound.
3. Confirm scope in writing in both drafts. Named programs, entity scope and cloud counting, since neither model covers anything outside the list.
4. If a ULA fits, schedule certification two years before expiry. An early count is one you can stand behind, and it leaves time to fix gaps.
5. If a PULA fits, negotiate a defined conversion path at entry. There will be no natural moment to add one later. Our Oracle practice builds the comparison with you.

Frequently asked questions