Oracle Database Enterprise Edition allows up to three pluggable databases per container, without the Multitenant option. The fourth pluggable database crosses the boundary. The Admodum read on what counts, where the line sits and how the audit reads it.
From Oracle Database 19c onward, the multitenant architecture is the only supported architecture (the non-CDB architecture has been deprecated). Within that architecture, a container database (CDB) can host pluggable databases (PDBs). The publisher rule is that a Database Enterprise Edition licence allows the operation of up to three pluggable databases per container, without the separately-licensed Multitenant option.
The included-three rule is the published licensing posture for Database 19c, 21c and 23c. It is the load-bearing concession that allows the multitenant architecture to be adopted at no incremental licence cost up to three workloads per container.
The wider editorial sits in the Oracle pillar; the wider EE-vs-SE2 read sits at SE2 versus EE; the activated-options panorama sits at database options and management packs.
The boundary sits at the fourth pluggable database. The third PDB is the last PDB inside the included scope. The fourth PDB is the first PDB that requires the Multitenant option. There is no partial activation: as soon as the fourth PDB is created in a container, the Multitenant option is required for that container.
The Multitenant option is then licensed against the cores that the container runs on. The arithmetic reads against the processor metric and the core factor table: on Intel Xeon (core factor 0.5) running on 16 activated cores, the Multitenant option lands at 8 Processor licences. The Multitenant option list price is the same as the Database EE list price for many configurations, doubling the per-container licence cost.
The fourth PDB therefore reads as a material commercial event, not a routine database operation.
Every user-created pluggable database counts. Application PDBs, application root PDBs (in application container configurations) and proxy PDBs count. Cloned PDBs and refreshable-clone PDBs count. PDBs created from XML, from DBCA templates or from datafile snapshots count.
The PDB$SEED template does not count (it is the template PDB used to create new PDBs and exists in every container). The CDB$ROOT does not count (it is the root container itself).
Application root PDBs in application container configurations sit in a particular position: the application root counts as one PDB inside the included-three, and the application PDBs that descend from it each count as additional PDBs. The buyer-side discipline reads the application-container topology against the included-three boundary before deploying.
The LMS audit reads the DBA_PDBS view (or the V$PDBS dynamic view) to enumerate the pluggable databases inside each container. The PDB$SEED row is filtered out of the count; every other row counts. The audit additionally reads DBA_FEATURE_USAGE_STATISTICS to surface any activation of multitenant-specific features.
The wider audit anatomy is covered at the LMS audit anatomy; the LMS audit scripts that publish the relevant queries against the buyer estate are covered at LMS scripts.
The audit-quality discipline is to hold a current PDB inventory per container, refreshed at the cadence of new-PDB creation activity. A PDB created and dropped within the audit window is still readable in DBA_FEATURE_USAGE_STATISTICS; the inventory therefore covers transient PDBs as well as steady-state PDBs.
On OCI, Autonomous Database carries the Multitenant option as part of the service (no separate licence is required to operate four or more PDBs inside an Autonomous Database instance). Exadata Cloud Service and Exadata Cloud@Customer carry the same posture as on-prem under BYOL: the included-three rule applies, and the fourth PDB activates the Multitenant requirement against the BYOL position.
On the authorised cloud environments (AWS, Azure, GCP under the Cloud Authorisation document), the on-prem licence posture applies: the included-three rule applies, and the fourth PDB activates the Multitenant requirement against the BYOL position.
The OCI BYOL bridge into Exadata Cloud is covered at the OCI BYOL bridge; the authorised cloud environments are covered at the Oracle Cloud Authorisation document.
The buyer-side discipline holds a current per-container PDB inventory, a calendar of new-PDB creation activity, and a clear position on the application-container topology (where used). The audit-quality posture is to keep every container at three or fewer PDBs unless the Multitenant option is held, and to surface any drift before the next audit moment.
Where four-or-more PDBs are required, the architectural alternatives are to consolidate workloads into fewer PDBs (one PDB per application boundary, not one per microservice), to split workloads across multiple CDBs (each within the included-three), or to acquire the Multitenant option against the affected cores.
The wider engagement sits in the Oracle practice; the aggregated reading list sits in the Oracle knowledge hub; active audit moments route to Audit Defence; active renewal moments route to renewal programme.
The wider panorama of separately-licensed Database EE options.
A senior Admodum Oracle advisor will read your per-container PDB inventory and the audit posture on a private call. Active audit moments route to Audit Defence; active renewal moments route to the Renewal Programme.