Oracle Machine Learning (OML) for Autonomous Database — Licensing Rules

Oracle Machine Learning licensing covers the in-database machine learning capability that Oracle has shipped since Oracle Database 9i (originally branded Oracle Data Mining, then Oracle Advanced Analytics, and now Oracle Machine Learning). The capability includes 30+ in-database algorithms (classification, regression, clustering, anomaly detection, feature extraction, association rules, time series forecasting), the OML4SQL package, the OML4Py Python interface, the OML4R R interface, OML Notebooks (Apache Zeppelin-based), OML Services for model deployment, and AutoML for automated model selection.

The licensing position depends entirely on the deployment path. On Oracle Autonomous Database, OML is bundled with the consumption-based service at no separate option licence — the entire OML capability is included in the ECPU-hour rate. On self-managed Oracle Database Enterprise Edition, OML is a separately licensed Enterprise Edition option (the Oracle Machine Learning option, formerly the Oracle Advanced Analytics option) carrying a per-Processor or per-Named User Plus list price on top of the Enterprise Edition licence. The two models generate materially different commercial and audit exposure profiles. For the broader Oracle Database licensing framework see the Oracle Database licensing master guide.

The Oracle Machine Learning licensing model

OML on Autonomous Database — bundled

Oracle Autonomous Database includes the full OML capability bundled in the consumption-based ECPU-hour rate. The bundled scope covers OML4SQL (the PL/SQL interface to the in-database algorithms), OML4Py (the Python interface), OML4R (the R interface), OML Notebooks (the integrated notebook environment), OML Services (the model deployment REST API), AutoML (automated model selection), and the supporting tooling. Customers running OML workloads on Autonomous pay only the ECPU-hour consumption rate against the workload — no separate option licence, no per-model uplift, no per-training-job billing.

OML on self-managed Enterprise Edition — separately licensed option

Self-managed Oracle Database Enterprise Edition deployments require the Oracle Machine Learning option (formerly the Oracle Advanced Analytics option) to use the in-database OML algorithms. The OML option is a separately licensed Enterprise Edition option carrying a per-Processor or per-Named User Plus list price on top of the Enterprise Edition licence. The option covers the same algorithm catalogue as the Autonomous bundle, but the customer must hold the option licence explicitly for every Processor or Named User Plus that the OML workload runs against.

OML on Standard Edition 2 — not available

Oracle has restricted the OML option to Enterprise Edition only. Standard Edition 2 customers cannot use the in-database OML algorithms on self-managed deployments. SE2 customers wanting machine learning capabilities have two options — upgrade to Enterprise Edition with the OML option, or use external machine learning tooling (Python scikit-learn, TensorFlow, PyTorch, R) against data extracted from the SE2 deployment.

The OML option pricing and back-licence math

The list pricing

The OML option list prices above are indicative against the 2026 Oracle Technology Global Price List. The economic exposure on a self-managed Enterprise Edition deployment scales with the licensed Processor count — a 200-core Enterprise Edition deployment running OML workloads carries a $4.6m initial OML option licence outlay plus $1.012m annual support obligation if the option is not already in place.

The LMS audit finding math

The forensic LMS audit finding on undeclared OML usage typically applies Processor licence pricing against the full database CPU footprint at list, reaches back to the first observed use of the algorithms in the database audit log, and applies the missed annual support obligation across the full lookback period. A 200-core deployment with three years of undeclared OML usage generates a back-licence claim of approximately $4.6m (initial licence) plus $3.036m (three years of support uplift) — a $7.6m total exposure before any commercial settlement negotiation. The settlement multiplier is the negotiated discount Oracle applies against the list claim — typically 30-60% off list at settlement, but the negotiation starts from the full-list claim and only moves under buyer-side pressure.

The detection mechanics

Oracle LMS detects OML usage through two primary mechanisms during a script-based audit. First, the V$OPTION view exposes the option enablement status — if the OML option shows enabled, LMS treats the option as in use. Second, the V$FEATURE_USAGE_STATISTICS view exposes the historical feature usage for the OML algorithms (Advanced Analytics, Data Mining, OML4SQL) — if the view shows non-zero usage counts across the audit lookback period, LMS treats the option as in use regardless of the current enablement state. The forensic defence has to address both detection vectors.

The audit defence framework for OML

Pre-audit entitlement check

The forensic defence starts with the pre-audit entitlement check. The customer should run the V$FEATURE_USAGE_STATISTICS query across every production database, every non-production database, every backup-restored database, and every DR standby — looking for OML4SQL, Data Mining, Advanced Analytics, or related feature usage. The check should reach across the full audit lookback window (typically three years). Any non-zero usage count requires either the OML option licence on the affected deployment, or a documented remediation to remove the usage and the supporting cleanup of the V$FEATURE_USAGE_STATISTICS history.

The shadow-IT exposure

The shadow-IT exposure on OML is material. Application teams, data science teams, and developers frequently experiment with OML4SQL or DBMS_DATA_MINING without recognising the option licence requirement. The exposure surfaces when the LMS audit reads V$FEATURE_USAGE_STATISTICS and shows historical usage from the experimentation. The defence requires both technical controls (database-level role-based controls preventing application teams from invoking the OML packages) and commercial controls (an explicit option enablement policy requiring commercial sign-off before any team uses the OML capability).

The Standby and DR exposure

OML usage on a primary database that replicates to a standby through Active Data Guard creates a compliance gap on the standby unless the OML option is licensed on the standby footprint. The same applies to backup-restored copies, test/development databases populated from production, and DR failover environments. Oracle's playbook treats every database footprint where OML usage is observed as a separate option licence requirement. The forensic defence requires the entitlement check across every database in the estate, not just production.

The Autonomous-versus-self-managed economic comparison

The total cost of an OML workload

For greenfield OML workloads, the Autonomous Database path frequently wins on total cost. The customer pays the consumption-based ECPU-hour rate against the actual workload — training jobs consume material ECPU-hours but only while running, and the bundled OML capability removes the separate option licence outlay. A 16-ECPU Autonomous Database running 24x7 lands at approximately $47k per year for the full database and OML capability — compared with a self-managed 8-Processor Enterprise Edition deployment at $384k (Enterprise Edition) plus $184k (OML option) plus $125k annual support, totalling $568k initial outlay plus $125k annual support.

The brownfield decision

For brownfield workloads with existing Enterprise Edition licence equity and existing OML option entitlement, the self-managed path typically wins on incremental cost — the OML capability is already paid for, and the Autonomous migration would generate a parallel ECPU consumption against the existing licence equity. The buyer-side analysis should model both paths against the actual workload forecast and the existing licence position. For the broader migration commercial framework see our Oracle cloud advisory service.

The Universal Credits absorption

Autonomous Database OML workloads consume Universal Credits against the customer's OCI commercial commitment. Customers with material Universal Credits commitments can negotiate the Autonomous ECPU rate at the commitment-based discount tier — typical discount tiers run 25-45% off published ECPU rate depending on the commitment size. The buyer-side analysis should treat the OML workload Autonomous consumption as part of the broader Universal Credits commercial conversation.

"Oracle Machine Learning licensing is a study in two distinct commercial models. The Autonomous bundle is genuinely commercially friendly. The self-managed option attach is one of Oracle's most aggressive audit findings. The buyer-side defence requires either the option licence held forensically against the actual database footprint, or the workload migrated to the Autonomous path with the consumption negotiated against the Universal Credits commitment."

An anonymised case study — UK financial services customer, OML option remediation

A UK financial services customer running a 96-Processor Oracle Database Enterprise Edition footprint discovered during a pre-audit forensic review in late 2025 that several application teams had been experimenting with OML4SQL classification algorithms across production and non-production databases for approximately 28 months. The V$FEATURE_USAGE_STATISTICS evidence showed non-zero usage counts across 14 databases covering an aggregate 78 Processors of the deployment footprint. The exposure profile if surfaced in an LMS audit was approximately $1.8m of OML option licence backclaim plus $396k of missed annual support — a $2.2m total exposure at list.

The buyer-side remediation framework worked three parallel tracks. Track one was the technical remediation — database-level role-based controls preventing application teams from invoking the OML packages, the V$FEATURE_USAGE_STATISTICS reset across the affected databases (where supported by the database version and the documented Oracle procedure), and the workload migration of the legitimate OML use cases to the Autonomous Database environment with bundled OML. Track two was the commercial remediation — an explicit option enablement policy with database-level controls, an inventory of legitimate use cases, and the forward-looking commercial decision on which workloads warranted the OML option licence going forward.

Track three was the audit defence preparation — a forensic documented entitlement position covering every database in scope, a positive workload migration narrative away from the self-managed exposure, and the buyer-side commercial provisions to negotiate against the residual exposure if it surfaced in a future audit. Outcome — the audit did not surface during the remediation window, the residual self-managed OML workload was scoped to 12 Processors with the option licence procured at a 58% discount against list ($231k initial outlay plus $51k annual support), and the bulk of the OML workload migrated to Autonomous against the Universal Credits commitment. Net commercial outcome: $1.92m of exposure avoided. For the broader Oracle audit defence framework see our Oracle audit defence guide.

The five buyer-side moves on Oracle Machine Learning

Move 1 — Run the V$FEATURE_USAGE_STATISTICS forensic check across every database. Production, non-production, backup-restored, standby, DR — every footprint where OML usage might surface needs the entitlement check. Reach across the full audit lookback window.

Move 2 — Implement database-level role-based controls on the OML packages. The shadow-IT exposure is real. Application teams experiment with OML4SQL or DBMS_DATA_MINING without recognising the option licence requirement. The technical control prevents the exposure.

Move 3 — Model Autonomous against self-managed for greenfield OML workloads. For new workloads without existing OML option equity, Autonomous typically wins on total cost. Model the workload forecast against both paths before the deployment.

Move 4 — Scope the self-managed OML option to the actual workload footprint. If the self-managed path is the right answer, the OML option should be procured against the actual workload core count, not the full database licence footprint. Workload isolation is the cost control.

Move 5 — Negotiate the Universal Credits absorption on Autonomous OML consumption. Autonomous OML workloads consume Universal Credits at commitment-based discount tiers. Treat the consumption as part of the broader OCI commercial conversation, not as a separate transaction.

Frequently asked questions

Is Oracle Machine Learning free on Autonomous Database?

Yes — Oracle Machine Learning is bundled with Oracle Autonomous Database at no separate option licence charge. The OML4SQL in-database algorithms, the OML4Py Python interface, the OML4R R interface, OML Notebooks, OML Services for model deployment, and AutoML are all included in the Autonomous Database consumption-based ECPU pricing. Customers running OML workloads on Autonomous pay only the standard Autonomous ECPU-hour rate. The economic exposure on Autonomous is the consumption profile of the OML workload — training jobs and model scoring at scale consume material ECPU-hours.

Do I need the Oracle Advanced Analytics option on self-managed Database Enterprise Edition?

Self-managed Oracle Database Enterprise Edition deployments using the OML in-database algorithms require the Oracle Machine Learning option licence (formerly the Oracle Advanced Analytics option). The OML option covers the in-database machine learning algorithms (classification, regression, clustering, anomaly detection, feature extraction), the OML4SQL package, and the Oracle Data Mining functions. The option is licensed per Processor or Named User Plus on top of the Enterprise Edition licence — a separately licensed Enterprise Edition option that frequently surfaces in LMS audit findings when customers use the algorithms without holding the option licence.

What is the audit exposure on Oracle Machine Learning on Enterprise Edition?

The audit exposure on self-managed Oracle Machine Learning workloads is one of Oracle LMS's more aggressive playbook items. The OML in-database algorithms are accessible through standard SQL and PL/SQL packages without any visible 'option enabled' switch — application teams frequently invoke DBMS_DATA_MINING or the OML4SQL functions without recognising the option licence requirement. LMS audit findings on OML typically reach back to the first observed use of the algorithms and apply Processor licence pricing against the full database CPU footprint, which can generate seven-figure back-licence claims against mid-sized deployments. The forensic defence is the entitlement check before the workload deployment, not after the audit notice.

Does OML4Py or OML4R require a separate licence?

OML4Py (the Python interface to OML) and OML4R (the R interface to OML) are bundled with the same OML option licence on self-managed Enterprise Edition deployments — there is no separate per-language interface licence. On Autonomous Database the OML4Py and OML4R interfaces are part of the bundled Autonomous Database service at no additional cost. The constraint on self-managed deployments is that any use of OML4Py or OML4R that invokes the in-database algorithms requires the OML option licence on the underlying Enterprise Edition deployment.

Related reading