Oracle Database 23ai changes the feature set, not the licensing rules. The release is positioned as a long-term-support version and the foundation for Oracle's AI-related database capabilities, but the way you license it is the same framework that has governed Oracle Database for years: choose an edition, choose a metric, and license any separately chargeable options and management packs on top. The risk with a major release is not a new rulebook — it is enabling a new feature without checking which licence bucket it falls into. This guide sits inside our broader Oracle licensing guide.
Standard Edition 2 versus Enterprise Edition
The first decision is edition. Standard Edition 2 (SE2) is the lower-cost edition with capped socket and processing limits and a restricted feature set; many advanced options are simply not available on it. Enterprise Edition (EE) removes those caps and unlocks the full catalogue of separately licensed options. The trap is choosing EE for one feature and then leaving the door open to enabling other chargeable options inadvertently. If your workload genuinely fits within SE2's limits, it is usually the cheaper and lower-risk choice.
Named User Plus and Processor metrics
Enterprise Edition is licensed either per Named User Plus (NUP) or per Processor. NUP counts the individuals and devices that access the database, subject to Oracle's published per-processor minimums, and suits environments with a small, countable user population. The Processor metric counts physical cores adjusted by Oracle's core factor table and suits large, internet-facing or unknown-user-count workloads. Choosing the wrong metric is one of the most expensive licensing mistakes, because switching later is a commercial negotiation, not a flick of a switch.
| Metric | How it counts | Best fit | Watch out for |
|---|---|---|---|
| Named User Plus | Per user/device, with per-processor minimums | Small, countable user base | Minimums can exceed actual users |
| Processor | Cores × core factor | Large or public-facing workloads | Virtualisation and core counting |
Separately licensed options and packs
The cost of an Enterprise Edition estate is usually driven by options and management packs, not the base licence. Options such as partitioning, advanced security, multitenant beyond the included pluggable-database allowance, and the diagnostic and tuning packs are all licensed separately and must be entitled across every core or user where they run. Many are trivially easy to enable and are switched on during routine administration. Our Advanced Compression note walks through exactly how an option becomes an obligation.
The AI-feature question: 23ai introduces database-resident AI capabilities such as vector search. Before you build them into production, confirm in writing which capabilities are included in Enterprise Edition and which — if any — require a separate option or pack. New features are precisely where included-versus-extra boundaries are least understood, and where audit findings cluster on a fresh release.
Deployment affects counting, not the rules
Whether you run 23ai on-premises, on Engineered Systems, or in the cloud, the editions, metrics and options are the same — what changes is how cores or OCPUs are counted. On Cloud@Customer and Exadata you license to enabled OCPUs; on virtualised on-premises infrastructure, processor counting and Oracle's partitioning policy become the dominant exposure. Match the metric to the deployment before you sign, not after.
Getting the position right
The defensible approach to a 23ai rollout is to inventory which editions, options and packs are actually in use across the estate, reconcile that against owned entitlements, and disable anything chargeable that is not needed before it accrues a liability. For a structured review of a 23ai migration or a true-up ahead of renewal, see our Oracle licensing experts service and the Oracle vendor hub.
Virtualisation and core counting
Where 23ai runs on virtualised infrastructure, the dominant licensing exposure is how Oracle expects processors to be counted. Oracle distinguishes between partitioning technologies it recognises as capacity-limiting and those it does not, and the distinction has a direct cost consequence: on technologies Oracle treats as soft partitioning, it generally expects the Database to be licensed for the full physical capacity the software could run on, not the subset you have allocated. This is the single biggest source of unexpected liability on virtualised estates, and it is unchanged in 23ai. Before deploying onto a shared virtualisation platform, confirm how the cores will be counted and design the placement of Oracle workloads accordingly.
Multitenant and pluggable databases
23ai continues Oracle's multitenant architecture, in which a container database hosts pluggable databases. A limited number of pluggable databases is permitted without the separately licensed Multitenant option; beyond that allowance, the option is required. Because consolidation projects naturally push the pluggable-database count upward, this is an easy threshold to cross without noticing. Track the pluggable-database count against the included allowance as part of routine governance.
A pre-deployment checklist
Before a 23ai rollout, settle five questions in writing: which edition each workload requires, which metric applies, which options and packs will be enabled, how cores or OCPUs are counted on the chosen infrastructure, and which new AI-related features fall inside or outside the base entitlement. Resolving these up front is far cheaper than reconciling them during an audit. The full option catalogue and metric detail sit in our Oracle licensing guide.