Oracle Database Container Licensing

Understanding CDBs and PDBs

Oracle Database's multitenant architecture, introduced in Oracle Database 12c, enables a single Container Database (CDB) to host multiple Pluggable Databases (PDBs). Each PDB appears to applications and users as an independent Oracle database — with its own schema, data, and configuration — but physically shares the CDB's single set of background processes, memory structures, and redo logs. This architecture enables significant consolidation: where an organisation previously needed twelve separate Oracle Database instances (each on its own server with its own full processor licence requirement), twelve PDBs within a single CDB on a single server can require only the processor licences for that single server.

The consolidation potential is real and commercially significant. However, realising it without triggering the Multitenant option licence requirement demands careful planning of your CDB topology and active governance of PDB creation. The licensing rules that govern how many PDBs you can host without additional cost are specific, and the absence of a technical enforcement mechanism means violations accumulate silently.

The Three-PDB Free Allowance

Since Oracle Database 19c, Oracle permits up to three user-created PDBs per CDB without requiring a Multitenant option licence. This applies to both Enterprise Edition and Standard Edition 2, and applies in on-premises, OCI, and non-Oracle cloud environments equally. The three-PDB limit includes only user-created PDBs — the PDB$SEED (the template PDB used to create new PDBs) and the root container (CDB$ROOT) do not count toward this limit.

Prior to Oracle Database 19c, the rules were more restrictive. In Oracle Database 12c and 18c, only one user-created PDB was permitted per CDB without a Multitenant licence. Any organisation that migrated to 19c and assumed their previous single-PDB CDB topology was now licensed for three PDBs should verify this assumption explicitly — the 19c expansion of the free allowance was a significant change, and it applies only from that version onward.

When the Multitenant Option Becomes Required

The moment a CDB hosts a fourth user-created PDB, the Oracle Multitenant option must be licenced. The Multitenant option is priced at $17,500 per processor (or $350 per Named User Plus), applied at the CDB level — meaning you licence the processors running the CDB, not individual PDBs. Once licensed, the CDB can host up to 252 user-created PDBs. This scalability is a genuine benefit of licencing Multitenant: the per-PDB cost of consolidating large numbers of databases into a single CDB can be substantially lower than the per-server processor cost of running them individually.

Annual support for the Multitenant option, like all Oracle licences, increases by 8% per year. This compounding effect must be included in any multi-year cost model. The Multitenant option is an Enterprise Edition option — it cannot be added to Standard Edition 2, which is limited to the three-PDB free allowance.

The Silent Compliance Risk: No Technical Block

Oracle does not enforce a hard technical limit on the number of PDBs in a CDB. A DBA can create a fourth, fifth, or tenth PDB in a CDB without the database engine raising an error or blocking the operation. This is the central compliance risk of the Oracle multitenant licensing model: violations accumulate silently, without any system-level notification, until they are surfaced by an Oracle LMS audit or an internal licence review.

In practice, this means that organisations running active database consolidation projects — migrating smaller databases into shared CDBs as part of a cost reduction or infrastructure modernisation programme — are at high risk of crossing the four-PDB threshold without a licensing review. DBAs focused on consolidation goals are unlikely to pause and check licence entitlements before creating each new PDB. Without a governance control that requires licensing sign-off before any PDB creation in a production CDB, the violation will happen.

Licensing Applies at the CDB Level, Not the PDB Level

A critical nuance of Multitenant licensing is that it applies to the CDB as a whole — specifically, to every processor on which the CDB runs. If a CDB runs on a server with 8 processors (after Oracle's Core Factor Table is applied), the Multitenant option must be licenced for all 8 processors, not just for the PDB count that exceeded the free limit. This is consistent with Oracle's general rule that options must be licenced on every processor where they are installed or in use, not just on the processors most actively using the feature.

In a RAC environment where a CDB spans multiple nodes, the Multitenant option must be licenced for every processor on every node in the cluster. This can make the Multitenant option cost in a large RAC cluster substantially higher than a simple two-node calculation would suggest.

Cloud Deployments: The Same Rules Apply

Oracle applies the same three-PDB free limit to non-Oracle cloud environments (AWS, Azure, Google Cloud) as it does on-premises. There is no cloud-specific relaxation of the Multitenant rule. Organisations that have migrated Oracle Database workloads to AWS or Azure and are using CDB/PDB architectures there must ensure they either remain within the three-PDB limit per CDB or hold the Multitenant option licence. This is an area that cloud migration projects frequently underestimate: the focus is on the base database licence mechanics under Oracle's cloud licensing policy, and the Multitenant option requirement is missed in the licence uplift calculation.

On Oracle Cloud Infrastructure (OCI), the same rules apply but are more naturally managed because OCI's managed database services enforce Oracle's licence terms at the service level. For self-managed Oracle on OCI (IaaS), the same governance framework applies as for on-premises.

Consolidation Strategy: Maximising the Free Allowance

The three-PDB free limit, properly exploited, can deliver significant licence cost reductions in consolidation programmes. The key is to design your CDB topology to maximise the use of the free allowance before purchasing the Multitenant option. For example, an organisation migrating 15 standalone Oracle databases onto a consolidation server could structure three CDBs with three PDBs each (9 databases in three free-limit CDBs) plus two additional CDBs or standalone installations for the remaining six, depending on workload characteristics and server count. This approach avoids Multitenant option costs for all 15 databases.

However, this approach has architectural trade-offs. Running multiple CDBs on a single server increases administrative complexity, and the performance isolation between PDBs within a CDB depends on resource management configuration. The optimal consolidation topology must balance licence cost, performance requirements, and management overhead — a calculation that benefits from independent specialist input before the architecture is committed. See our Oracle licensing advisory specialists for consolidation planning support.

Governance Controls for Multitenant Compliance

Effective multitenant licence compliance requires governance controls at the DBA and architecture level. Redress Compliance recommends implementing the following: a pre-creation approval process for any new PDB addition to a production CDB, with explicit licence entitlement verification as a precondition; a quarterly inventory of all CDBs and their PDB counts, cross-referenced against Multitenant option entitlements; and an automated alert — using Oracle's own DBA_PDBS view — that notifies the licensing team when a CDB's PDB count approaches or exceeds the relevant limit. These controls are simple to implement and prevent the most common and costly multitenant audit finding.