Oracle / ULA
Oracle PULA vs Oracle ULA. The two unlimited models.
A ULA and a PULA promise the same unlimited deployment, then split on term, certification, support, and audit. This comparison shows which unlimited model fits your estate.
A ULA and a PULA promise the same unlimited deployment, then split on term, certification, support, and audit. This comparison shows which unlimited model fits your estate.
Oracle sells two unlimited license models that look identical on the cover and behave very differently in practice. This comparison breaks down how a ULA and a PULA each treat term, certification, support, and audit, so you can pick the one your estate actually needs.
The names invite confusion. A ULA is an Unlimited License Agreement. A PULA is a Perpetual Unlimited License Agreement. One word, perpetual, is the whole difference.
Read past the cover and the two models split on four axes. Term, certification, support, and audit. Get those four clear and the choice is straightforward.
The ULA has an end. The PULA does not. That boundary defines every downstream difference.
A ULA runs for a defined period, commonly three years. You deploy without counting during the term, then the term closes and the certification process begins.
A PULA has no closing date. The unlimited right and the support obligation both continue indefinitely, which is attractive only if you keep deploying the named programs for many years.
The table compares the structural facts. Use it to frame the lifetime model, not as a quote.
ULA and PULA structure compared
| Attribute | ULA | PULA |
|---|---|---|
| Duration | Fixed term | Perpetual |
| Certification | At expiry | Never |
| Count outcome | Frozen at exit | Open ended |
| Support reset | Possible after exit | No reset point |
| Renewal pressure | Every cycle | None, but locked in |
Certification is the single most consequential event in a ULA lifecycle. It converts unlimited usage into a fixed, perpetual entitlement.
You measure deployed quantities of the named programs and declare them to Oracle. Oracle converts the declared count into perpetual licenses, and that number becomes your support base going forward.
The count depends on processor and core math, including the licensing rules Oracle publishes and the partitioning policy. Virtualized estates need careful measurement to avoid an inflated assertion.
Because a PULA never certifies, there is no moment to lock a number or to reset support. The deal you signed is the deal you keep paying, which is why the PULA entry terms carry so much weight.
Support, not license fee, is where the lifetime difference shows up. The two models treat the support stream in opposite ways.
After certification you can review the certified estate and drop support on unused options under Oracle's support policy. That reset is the ULA's hidden value.
A PULA support stream continues with no reset point. Over a decade, a perpetual support obligation on a stable estate can dwarf the savings of never certifying again.
Compare both models across ten years, including support escalation against the published technology price list. The model that wins on the signing fee often loses once the support annuity is summed.
The standard reseller and account team line is that a PULA is the premium, worry free option and a ULA is the budget choice you will regret at renewal. We disagree. In roughly 6 of 10 comparisons we have run with both models priced, the deciding factor was not comfort but the deployment trajectory, and the ULA won clearly whenever the estate was stable or heading to cloud. The buyer side move is to ignore the framing entirely, build a ten year lifetime support model for both options from your own capacity plan, and let the trajectory choose the model rather than the sales narrative.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
A ULA and a PULA are not a premium and a budget version of the same thing. They are two different bets on whether your Oracle estate keeps growing.
Both models protect the named programs inside scope and nothing beyond it. The audit difference is about friction, not immunity.
Programs not named, options not listed, and entities not covered are normal audit exposure under either model. Oracle License Management Services probes those edges first.
A PULA lowers routine measurement friction on the named programs because there is no certification to defend. A ULA concentrates audit attention at the certification event, where the count is fixed.
Both models raise cloud counting questions as workloads move to authorized cloud environments. Confirm in writing whether cloud deployments count toward the right before you sign.
PULA stands for Perpetual Unlimited License Agreement. It carries the same unlimited deployment right as a ULA for a named set of Oracle programs, but it never expires and never certifies, so the count and the support stream continue indefinitely.
The core difference is the term. A ULA is fixed and certifies to a frozen perpetual count at expiry, while a PULA is perpetual with no certification and no end. That single difference drives the support cost, the audit profile, and the negotiation.
It depends on trajectory. A PULA is cheaper only when deployment keeps growing on the named programs for the full horizon. For a stable or shrinking estate, a ULA with a disciplined certification is usually 20 to 35 percent cheaper across ten years.
No. A PULA has no certification event and no reset point, so the support stream runs indefinitely. A ULA, by contrast, lets you certify, freeze the count, and drop support on unused options after exit, which is a major part of its lifetime value.
The certified count is the measured deployment of the named programs at expiry, converted to perpetual licenses using Oracle's processor and core rules. Virtualized estates need careful measurement, because soft partitioning can inflate the count Oracle asserts.
Only on the named programs within the agreed scope. A PULA lowers routine measurement friction but does not cover unnamed options, products outside the list, or entities outside scope. Those remain normal audit exposure under either unlimited model.
A PULA secures a perpetual support annuity for Oracle, which is why it is frequently proposed even when the estate does not justify it. In most comparisons we run, Oracle favors the model that protects its recurring revenue rather than the buyer's trajectory.
Cloud migration favors the ULA. A perpetual on premises unlimited right becomes a stranded cost when workloads move to the cloud, while a ULA lets you certify a smaller production footprint and reduce support as the data center shrinks.
Yes. The trajectory, not the sales framing, should decide. Build a ten year deployment forecast from your own capacity plan, price both models against it, and let a growing, stable, or cloud bound trajectory choose the agreement.
It helps significantly. The decision sets your Oracle cost for a decade and the model that looks cheaper at signing often loses on lifetime support. Independent buyer side advisory builds the side by side lifetime comparison Oracle will not provide.
Oracle ULA exit moves, Java audit defense posture, certification framework, and the buyer side moves across the Oracle Database, Java, and EBS estate.
Used across more than five hundred enterprise engagements. Independent. Buyer side. Built for procurement and IT asset leaders running the next Oracle renewal or ULA cycle.
Do not let the names decide for you. A ULA and a PULA are two different bets on your Oracle future, and only your deployment trajectory knows which bet is right.
