Oracle Multitenant Licensing

Multitenant is unusual among Oracle options because the architecture it governs is now mandatory, while the option that unlocks its full value is not. Every modern Oracle database is a container database, but the right to run more than a handful of pluggable databases inside it is a paid option. That split, mandatory architecture and optional scale, is where consolidation projects walk into a licence charge. This article explains the free limit, the trigger, and how a buyer side estate consolidates without overspending. It sits under the database licensing pillar and the options and packs overview.

What is Oracle Multitenant?

Multitenant is the Oracle Database architecture in which a single container database, the CDB, hosts one or more pluggable databases, the PDBs. Each pluggable database behaves like an independent database to its application, while sharing the memory, background processes, and redo of the container. The architecture simplifies consolidation, patching, and cloning, because many databases can be managed as one while remaining logically separate.

The container architecture itself is mandatory in current releases, so every database is technically a container with at least one pluggable database. The Multitenant option is what permits running multiple pluggable databases at scale. The distinction between the free architecture and the paid scale is the entire licensing story, and it is as consequential as the metric choice covered in the Processor versus Named User Plus article.

The three pluggable database free limit

Oracle permits a limited number of pluggable databases in a container without the Multitenant option. In current releases this allowance is three user created pluggable databases per container, with the count rising in the most recent releases. Up to that limit, the container and pluggable architecture can be used at no option cost. The moment a fourth user pluggable database is created in the same container, the Multitenant option is required.

The limit is precise and version specific, and it counts user pluggable databases, not the seed or application root containers Oracle uses internally. Misreading the limit, or assuming an older free count applies to a newer release or vice versa, is a common error. The exact allowance for the database version in use must be confirmed, with the same precision applied to the Named User Plus minimums.

How Multitenant is licensed

When required, Multitenant is licensed on the same metric as the database and for the same quantity. A Processor licensed container needs the option for the identical core count with the same core factor; a Named User Plus container needs it for the same user count. The option is licensed at the container level for its full core footprint, regardless of how many pluggable databases exceed the limit. Going from three to four pluggable databases costs the same as going from three to thirty, because the trigger is binary.

This makes the consolidation economics interesting. Once the option is bought for a container, additional pluggable databases are effectively free of further option cost, so the marginal cost of consolidating more databases into a licensed container is low. The first step over the limit is the expensive one, following the all or nothing footprint rule shared with every option in the pack catalogue.

Why consolidation projects trigger the option

The classic trigger is a consolidation initiative. An infrastructure team sets out to reduce the number of database servers by plugging many small databases into a few containers, an architecturally sound goal that delivers real operational savings. But the moment any container holds a fourth pluggable database, Multitenant is required across that container's full core count, and the savings on hardware are offset by an unbudgeted option charge.

The trap is that the consolidation looks like pure efficiency until the licence implication is calculated. A buyer side estate plans the pluggable database distribution against the option cost from the outset, deciding which containers will be licensed for Multitenant and which will stay at three or fewer pluggable databases. The same planning discipline applies when consolidation interacts with clustered designs covered in the RAC licensing article.

How does Oracle detect Multitenant usage?

Oracle reads the feature usage statistics and the data dictionary, which record the number of pluggable databases in each container and whether the count has exceeded the free limit. The Multitenant feature is recorded with usage dates once the limit is passed. Because the pluggable database count is a structural fact visible in the dictionary, the finding is conclusive and easy for Oracle's scripts to establish.

The usage is also persistent. A container that briefly held four pluggable databases during a migration, even if it later dropped back to three, will have recorded the usage. This is the same instrumentation that drives the broader options audit, and it means transient over the limit states during project work leave a permanent trace.

What Multitenant costs

The option is licensed for the full container core count, so the cost scales with the size of the container, not the number of pluggable databases. The economic logic this creates is to consolidate aggressively into a small number of licensed containers rather than spread pluggable databases thinly across many. Once a container is licensed, packing more pluggable databases into it adds no further option cost while continuing to reduce hardware and management overhead.

Conversely, keeping every container at three or fewer pluggable databases avoids the option entirely, which can be the right answer for an estate with modest consolidation needs. The decision is a portfolio optimisation, balancing option cost, hardware savings, and operational simplicity, and it is exactly the modelling the database licensing service brings to a consolidation programme.

How to contain Multitenant exposure

Containment is a planning and monitoring exercise. The estate should decide deliberately which containers are licensed for Multitenant and which are capped at the free limit, and enforce that decision through provisioning standards so no container quietly acquires a fourth pluggable database. Migration runbooks should avoid transient over the limit states, or run them only on containers already licensed.

The standing controls are scheduled checks of the pluggable database count per container against the licensed position, and a clear rule that creating a pluggable database beyond the free limit requires a licence check. Where the option is owned, consolidation should be maximised into those containers to extract full value. Reconstructing the pluggable database history under audit defence is the costly alternative to monitoring it.

The buyer side view

The buyer side position on Multitenant is to treat the free pluggable database limit as a hard provisioning boundary and the option as a deliberate consolidation investment. Decide which containers are licensed and which are capped, enforce the distinction through provisioning controls, and where the option is bought, consolidate hard into those containers so every pluggable database beyond the limit is effectively free. Planned this way, consolidation delivers its hardware savings without an unbudgeted option charge. To model your own consolidation, see the database pillar, the database licensing white paper, or request a consultation.