Oracle Multitenant Licensing

Oracle Multitenant Licensing: Enterprise IT Advisory

Oracle Multitenant Licensing is a critical topic for IT asset managers as Oracle shifts its database architecture to a containerized model.

This advisory provides a detailed examination of how the Oracle Multitenant option operates on-premises, including costs and licensing rules (with version-specific nuances), as well as practical guidance to optimize costs and mitigate compliance issues.

It offers insights, real-world examples, and clear recommendations to help enterprises confidently manage Oracle Multitenant licensing.

Understanding Oracle Multitenant

Oracle Multitenant, introduced in Oracle Database 12c, allows multiple pluggable databases (PDBs) to run within a single container database (CDB). Instead of hosting multiple separate Oracle database instances, organizations can consolidate them into a single CDB with isolated PDBs.

This architecture improves resource utilization and centralizes management – for example, you can back up or patch the CDB once for all its PDBs.

Each PDB still behaves like a standalone database for applications, ensuring isolation and security.

In short, Oracle Multitenant simplifies database consolidation and administration, which is especially attractive in large enterprise environments.

However, these technical benefits come with licensing considerations that must be understood to fully realize the cost savings of consolidation.

Read Oracle Multitenant Licensing on AWS, Azure, and Oracle Cloud: Key Considerations for Hybrid Environments

Oracle Multitenant Licensing Basics

Oracle’s licensing for Multitenant is an optional add-on to Oracle Database Enterprise Edition (EE).

If you use Oracle’s multitenant architecture on-premises, whether you need to purchase this option depends on the number of PDBs per CDB and the database version:

• Oracle Database 12c, 18c (Enterprise Edition): Single-tenant mode – You can create 1 user-created PDB per CDB without the Multitenant license. If a CDB contains two or more PDBs, the Multitenant option must be licensed.
• Oracle Database 19c and later (Enterprise Edition): Up to 3 PDBs free – You are allowed up to 3 user-created PDBs in one CDB without requiring the Multitenant license. If you have 4 or more PDBs in a CDB, the Multitenant option is required. (Oracle made this change in 19c to encourage adoption, as non-container architecture is deprecated from 21c onward.)
• Standard Edition 2 (all versions): No Multitenant option available – SE2 supports the container architecture with only one PDB. You cannot license the Multitenant option on SE2, and the software will not allow more than one PDB in a Standard Edition database. Essentially, multi-PDB configurations are a feature exclusive to the Enterprise Edition.

Importantly, Oracle’s database software does not automatically enforce the license limits on PDB count for Enterprise Edition. It’s the customer’s responsibility to remain compliant.

For example, in Oracle 19c EE, you can technically create a fourth PDB; however, doing so without the Multitenant license would put you out of compliance.

If Oracle conducts an audit, any CDB with too many PDBs would be flagged for license violation.

In any version, one CDB with multiple PDBs is counted as one database instance for licensing purposes. However, if it exceeds the free PDB allowance, the Multitenant option must be licensed for that instance.

Another key point: A single Multitenant license covers all PDBs in a container (up to the technical maximum). You do not need to license each PDB separately.

However, if you have multiple CDBs on different servers, each environment must be licensed if it exceeds the free PDB limits.

For enterprises planning to consolidate dozens of databases, understanding this licensing model is crucial to avoid unexpected costs.

Read Oracle Multitenant Licensing Compliance: Audit and Best Practices for Enterprises.

Licensing Models and Costs for Multitenant

Oracle Multitenant licensing is available under two metrics: Named User Plus (NUP) and Per Processor.

These follow the same definitions as other Oracle database licenses:

• Per Processor License: Based on the number of processor cores in the servers where the CDB is running. Oracle’s core factor table applies (for instance, on x86 processors, a core typically counts as 0.5, so two cores equal one licensed processor). This metric is common for server-based licensing with a large number of users.
• Named User Plus License: Based on the number of distinct users (including humans or devices) that access the Oracle databases. NUP licensing has a user minimum (usually 25 NUP per processor for Enterprise Edition), so it’s usually viable in environments with a limited user count or non-production systems.

Pricing: The Oracle Multitenant option is considered a premium add-on.

As of recent price lists, the list price for the Multitenant option on-premises is approximately $17,500 per processor (perpetual license) or $350 per Named User Plus.

These are one-time license fees (support renewal at ~22% annually is additional).

Enterprises with an Unlimited License Agreement (ULA) or volume agreements may negotiate discounts; however, without a special deal, the costs can be significant – often comparable to other expensive Oracle options, such as RAC.

Below is a summary of Oracle Multitenant on-prem licensing in terms of PDB allowances and cost:

Table: Oracle Multitenant Licensing – free usage vs. licensed option. Note that 252 is the typical technical limit of PDBs in a CDB (on conventional hardware); Oracle extends this limit to 4,096 PDBs on engineered systems, such as Exadata.

In practice, very few organizations will approach these maxima, but the license allows it. The key takeaway is that purchasing the Multitenant option removes the 1 or 3 PDB limitation, allowing you to consolidate multiple databases into a single CDB. The trade-off is the substantial license cost, which the benefits of consolidation must justify.

Choosing NUP vs Processor: For enterprises, processor-based licensing is usually simpler, as user counts can be large or difficult to track.

However, if you have a controlled user base (for example, a set of internal applications with a limited number of service accounts), NUP licensing might save money.

Always check Oracle’s minimums and consider future growth; if there’s any uncertainty in user count, the per-processor model may be safer despite the high cost per core.

Read Oracle Multitenant Licensing Cost Optimization: Strategies for CIOs to Reduce Costs.

Consolidation Benefits vs. License Costs

The promise of Oracle Multitenant is efficient consolidation, allowing multiple databases to run on a single platform, which can reduce hardware, power, and management overhead.

For instance, instead of ten separate Oracle servers each running one database instance, you could have one robust server running one CDB with ten PDBs.

This yields savings in data center resources and simplifies operations – a single backup or patch can cover all ten databases.

However, licensing costs can offset these savings if not carefully managed. In the above example, if those ten databases are consolidated into one CDB, you cross the “3 PDBs free” threshold, meaning you must license the Multitenant option for that server.

You would pay for the base Oracle EE licenses for the server plus the Multitenant option licenses. If the server has, say, 8 processors (after core factoring), the Multitenant option would list at 8 x $17,500 = $140,000 (one-time, plus approximately $ 30,000 per year in support).

This cost might be acceptable if consolidation allowed you to eliminate multiple other EE licenses or expensive hardware.

But if those ten databases were previously running on one or two servers without requiring the option, the consolidation could increase your software licensing spend significantly.

Real-World Example: A global financial firm planned to consolidate five Oracle 12c databases into one container database for easier management.

Each database was small, and the goal was to cut infrastructure costs by using one large server instead of five smaller ones. However, under Oracle’s licensing rules, having five PDBs in one CDB meant the company needed to purchase the Multitenant option.

The server had 16 cores (8 processors after Oracle’s core factor), so at list price, the new license would cost roughly $140,000, plus $30,800 in annual support. This came as an unbudgeted surprise, partially negating the hardware savings.

In the end, the firm negotiated a discount with Oracle and proceeded with consolidation due to the operational benefits, but the case illustrates why cost modeling is essential.

The lesson: always factor in Oracle Multitenant licensing when calculating the ROI of database consolidation.

To maximize value, enterprises often consolidate up to the “free” limit first – e.g., use 2 or 3 PDBs in Oracle 19c without buying the option – and only exceed that when there’s a clear cost-benefit justification.

Remember that running multiple separate databases (each as a single PDB in its own CDB on the same server) does not require the Multitenant license.

In other words, you could create multiple Oracle instances on one physical server (or VM,) each with one PDB, and avoid the Multitenant fee (though you’d still need to license the server for Oracle EE).

This separate-instance approach sacrifices some of the technical advantages of true consolidation, but it can be a cost-conscious strategy if you want to avoid the Multitenant option. Each approach should be weighed for its operational benefits versus licensing impact.

Common Pitfalls and Compliance Risks

Oracle Multitenant licensing can be a trap for the unwary.

Here are some common pitfalls ITAM professionals at large enterprises should watch out for:

• Accidental Non-Compliance: A DBA creates an extra PDB not realizing it breaches the license limit. Oracle’s software won’t stop you, but an audit will flag any CDB with too many PDBs as requiring a license. Even a temporary fourth PDB (for example, cloning a PDB for testing purposes) can be considered usage. Always monitor PDB count in each environment and enforce internal policies to prevent unlicensed usage.
• Version Misunderstanding: Organizations sometimes upgrade to Oracle 19c and assume the 3 PDB free allowance applies to all environments. Remember, if you still have older 12c/18c instances, the old “1 PDB only” rule applies there. Mixing up the version-specific rules can lead to compliance issues. Standard Edition environments, likewise, should never have more than one PDB. Keep track of Oracle versions in use and their respective license entitlements.
• Ignoring the 21c Architecture Change: Starting in Oracle 21c (and upcoming 23c LTS), you must use the CDB/PDB architecture — non-pluggable databases are no longer supported. This effectively forces you into Multitenant mode, at least in single-tenant mode, and may prompt more organizations to consider using multiple PDBs. If you plan to adopt newer Oracle versions, include Multitenant licensing in your roadmap (or ensure you stick to the free PDB limit). Not planning for this can leave you scrambling for budget or stuck on out-of-support versions to avoid licensing fees.
• Contract and ULA Exclusions: Oracle Unlimited License Agreements or enterprise contracts often do not automatically include all options. A common pitfall is assuming your ULA covers Multitenant – many do not, unless it’s explicitly negotiated. The Multitenant option might need to be purchased separately or added to a ULA. Always double-check your contracts and ULAs: if Multitenant is not included and you deploy it, you’ll face a hefty bill later. Proactively negotiate for needed options while you have leverage (e.g., at renewal time) rather than after an audit.
• Lack of Internal Controls: Without proper controls, developers or DBAs may freely create new PDBs, inadvertently causing non-compliance. Enterprises should restrict who can create PDBs and use Oracle’s profiles or Resource Manager to enforce limits. Instituting a policy (and tooling if possible) to require approval for creating additional PDBs can save you from surprise licensing exposures.
• Assuming Technical = Licensed: Don’t assume that because Oracle’s technology allows something, it’s included in your license. The Multitenant architecture is enabled by default in newer Oracle versions. It’s easy to start using PDB features, such as cloning or unplugging/plugging, unaware that beyond a certain point, they become a paid feature. Regular training and awareness for your database administrators and architects is critical so they understand where the “free” usage ends. Conduct periodic internal audits of your Oracle deployments to catch any inadvertent use of extra PDBs.

By learning from these pitfalls, organizations can proactively manage Oracle Multitenant usage and avoid financial surprises.

In summary, always align your technical implementation with your licensing position if you need the benefits of multiple PDBs; factor in the licensing requirements from the start. If you want to avoid extra costs, design around the limits and document those constraints for your teams.

Recommendations

To effectively manage Oracle Multitenant Licensing in an enterprise environment, consider these expert tips:

• Monitor PDB Counts Continuously: Implement a regular audit process or automated monitoring to track the number of pluggable databases in each Oracle instance. Catching an extra PDB early can prevent a licensing violation from escalating.
• Leverage the “Free” Allowance: Maximize usage of the free PDB limit (1 in older versions, 3 in 19c+) where possible. Consolidate smaller databases up to these limits to save on hardware and still avoid the Multitenant license fee.
• Plan for Growth: If there’s a chance you’ll need more than 3 PDBs in a CDB, plan the licensing and budget before deploying. It’s easier to get approval for the cost as part of a project than to justify an unexpected expense after an audit.
• Negotiate for Enterprise Agreements: If you anticipate heavy use of Multitenant, include it in your Oracle agreements. For example, consider including the Multitenant option in your ULA or seek bundle discounts when renewing your licenses. Oracle may be more flexible on price if you address it upfront.
• Restrict PDB Creation: Limit the ability to create or plug in PDBs to a small number of authorized DBAs. Implement internal controls or approval workflows. This prevents well-meaning staff from unknowingly breaching license terms.
• Educate and Document: Ensure your IT teams are aware of the licensing rules. Update your internal documentation and training to specify the number of PDBs allowed and the process for requesting additional ones. Awareness is one of the best defenses against accidental non-compliance.
• Evaluate NUP vs. Processor Licensing: Analyze your user counts versus processor counts to choose the most cost-effective license metric. For some non-production or limited-use systems, Named User Plus licensing for Multitenant can be significantly more cost-effective than per-processor licensing.
• Consider Alternatives for Small Databases: If you have only a few small databases, consider whether they truly need to be placed in a single CDB as PDBs. In some cases, running them as separate Standard Edition databases (if they fit the SE2 limits) or as separate single-tenant EE instances may avoid the Multitenant cost. Always weigh the operational convenience against licensing price.
• Stay Updated on Oracle Policies: Oracle’s licensing rules can evolve (as seen with the jump from 1 to 3 free PDBs). Keep an eye on Oracle’s official licensing documentation for any changes that could work in your favor or alter compliance requirements.
• Perform Internal Oracle Audits: Treat license compliance as an ongoing task. Periodically simulate an Oracle audit internally – use Oracle’s scripts or third-party tools to inventory your Oracle environment and verify that all Multitenant usage is accounted for under your licenses. This preparation can reveal issues early and also arms you with data if Oracle initiates an official audit.

Checklist: 5 Actions to Take

1. Inventory Your Databases: Identify all Oracle Database instances in your enterprise and note their versions and editions. Determine which ones are using the multitenant architecture (CDB/PDB) and how many PDBs each has.

2. Map Licensing Needs: For each Oracle instance, compare the PDB count against the allowed limit for that version. If any CDB has (or is planning to have) more PDBs than allowed, mark it as requiring the Oracle Multitenant license. Also, review whether you have purchased that license for those environments.

3. Enforce Policies Now: Implement a policy that no new PDBs are created without license review. Communicate this policy to your DBAs and architects. If possible, configure Oracle’s software (or management scripts) to alert or prevent when someone attempts to create a fourth PDB in a 19c instance (or a second PDB in 12c).

4. Optimize and Consolidate Wisely: Look for opportunities to consolidate databases up to the free limit – e.g., combine standalone databases into one CDB with 3 PDBs on 19c to reduce servers and EE licenses, while still avoiding the option cost. Conversely, avoid over-consolidating into a single CDB if it triggers a new Multitenant license, unless you have calculated that it’s worth the cost.

5. Plan for Future Upgrades: If you plan to upgrade to Oracle 21c or 23c in the next cycle, start your migration planning with licensing in mind. Decide whether to stick with a single-tenant option (no extra cost) or leverage multiple PDBs (budget for the Multitenant option). Engage your Oracle account reps early if you need to adjust your licensing agreements or seek a deal on the Multitenant option as part of the upgrade. Having a clear plan will prevent last-minute compliance surprises when the new version is deployed.

FAQ

Q: What exactly is Oracle Multitenant Licensing, and who needs it?
A: Oracle Multitenant Licensing refers to the license for Oracle’s “Multitenant” database option on Enterprise Edition. You need this license only if you run more than the allowed number of pluggable databases in a single Oracle CDB (Container Database). For Oracle 19c and later, up to 3 PDBs are free – the license is needed when you use four or more PDBs in one CDB. (On 12c/18c, the license was needed for 2+ PDBs.) If you never exceed those limits, you don’t need to purchase this option for on-premises use.

Q: Is the Multitenant option included with any Oracle Database editions or cloud services?
A: It’s not included with Standard Edition 2 – SE2 cannot use more than one PDB, and there’s no way to add the option. It’s an extra-cost option for Enterprise Edition on-prem. In Oracle’s cloud (such as Autonomous Database or Database Cloud Services), the Multitenant technology is used under the hood. Still, as a customer, you typically pay for the service rather than licensing the option separately. For on-premises Enterprise Edition, assume it’s an add-on unless you have a contract that says otherwise.

Q: How much does Oracle Multitenant cost, and is it worth it?
A: The list price is steep – roughly $17,500 per processor license for the Multitenant option (or $350 per named user). That’s on top of the Enterprise Edition database license. Whether it’s “worth it” depends on your situation: if you can consolidate many databases on one server, you might save on hardware, energy, and base EE licenses, offsetting the Multitenant fee. The option also offers technical benefits, such as easier database cloning and centralized management. Large enterprises with dozens of databases often find it beneficial despite the cost, whereas smaller setups might avoid it. Always conduct a cost-benefit analysis tailored to your specific environment.

Q: What are the risks if we ignore Oracle Multitenant licensing rules?
A: The biggest risk is license compliance exposure. Suppose Oracle audits your organization and finds you’ve been using more PDBs than allowed without the license. In that case, they can issue a hefty bill for back-dated licensing and support, or demand that you remediate immediately (which could mean shutting down databases or purchasing licenses under pressure). It can also jeopardize your Oracle relationship or negotiating position. There’s also an operational risk: if you suddenly have to reduce PDBs or purchase licenses unplanned, it can disrupt projects and budgets. It’s far better to remain compliant and address licensing proactively than to deal with audit fallout.

Q: How can enterprises optimize Oracle Multitenant usage to reduce costs?
A: Enterprises can optimize by carefully planning how they consolidate databases. Use the free PDB allowances to the fullest – for example, three PDBs in one 19c CDB is a sweet spot with no extra license fee. Avoid casually creating new CDBs each with a couple of PDBs (which might cumulatively push you into needing multiple licenses); instead, pack PDBs into as few CDBs as possible up to the free limit. If you truly need many PDBs, consider negotiating a better price for the option or factor it into a broader Oracle deal. Additionally, revisit whether all those databases need to be separate PDBs – perhaps some could be schemas within one database, or some Oracle instances could be replaced with lighter or cloud-based alternatives, depending on the requirements. Effective license management, architecture design, and vendor negotiation all play a role in minimizing the cost impact of Oracle Multitenant.

Read more about our Oracle License Management Services.

Do you want to know more about our Oracle Advisory Services?

Please enable JavaScript in your browser to complete this form.

Name *

First

Last

Email *

Company

Message *

Submit