Your Oracle Retail media pack ships a fully functional Oracle Database that is contractually boxed to run retail workloads only. This page shows exactly where that grant ends, how ordinary DBA habits break it, and what Oracle charges when its audit team reprices the footprint at Full Use.
Your Oracle Retail media pack ships a fully functional Oracle Database that is contractually boxed to run retail workloads only. This page shows exactly where that grant ends, how ordinary DBA habits break it, and what Oracle charges when its audit team reprices the footprint at Full Use.
When you licensed Oracle Retail Merchandising System (RMS), Sales Audit, Allocation, RPAS, or the planning modules on premise, you did not buy a general-purpose Oracle Database. You bought an Application Specific Full Use (ASFU) license, and that distinction is the single most expensive misunderstanding we see across the Retail install base. Oracle's own Fusion Middleware documentation states the design plainly: each Application Specific Technology product contains the same features as its full-use counterpart, but is restricted for use only with the eligible Oracle Application for which it is licensed.
The word "full use" is technically accurate and legally misleading. Every feature works. The metrics are the same Processor and Named User Plus counts you would find on a standalone Enterprise Edition license, including the 25 NUP per Processor floor. Nothing is crippled, nothing is edition-limited. The constraint is 100 percent contractual: you are licensed to run the named Oracle Retail application against that database and nothing else. The Oracle Retail Licensing Guide (14.1.x/14.2) confirms this module by module, noting for example that RMS uses restricted licenses, that Oracle Retail Sales Audit uses restricted licenses, that Oracle Retail Allocation uses restricted licenses, and that the media pack includes a Restricted Use license for RPAS Enterprise Engine to support Merchandise Financial Planning only.
It is full use in the technical sense and application specific in the legal sense. Nothing breaks when you overstep the grant. Nothing warns you either.
That silence is the entire problem. Because ASFU is byte-for-byte identical to Full Use, the moment your DBA team steps outside the retail scope the database keeps running perfectly. There is no error, no license check, no throttle. The breach is invisible until Oracle's audit team (LMS) reads your contract and reprices the whole footprint. If you want the deeper mechanics of the model itself, our ASFU licensing explainer covers the price gap and conversion traps in detail; this page focuses specifically on the Oracle Retail context.
The ASFU grant permits the end user to run Oracle Database only in direct support of the ISV's specific application. In the Oracle Retail case, the "ISV application" is the Oracle Retail module named on your ordering document. The database exists to serve that module and nothing more. Three boundaries matter most in practice:
There is one nuance that protects you and one that traps you. The Retail application's own built-in reporting, which uses Oracle internally, is allowed, because that reporting is part of the licensed application. But an external business intelligence tool that queries the Oracle database directly is not allowed under ASFU. This is the exact line where most breaches occur, and it is worth reading twice: internal application reporting is fine, external direct database access is not.
One more Oracle Retail specific point on scope. The Retail licensing documentation formally separates "entitled products" from "restricted use licenses," and states that entitled products and restricted use licenses do not apply to Oracle Retail Cloud products. If you are planning a move to the SaaS versions, the restricted-use database question disappears, but a new set of revenue-band and metric questions appears. We map those in our guide to moving from Oracle Retail on premise to cloud service.
The violations we find are almost never deliberate. They are the product of good engineering instincts applied to the wrong license. When your Oracle Retail estate is humming and you have a fully functional Enterprise Edition sitting there, it is natural for a DBA to treat it as spare capacity. That instinct is what Oracle bills for. The most common violation pattern is when a DBA team creates additional schemas on the same instance for reporting, data warehousing, or other purposes. Those uses violate the restriction even though the database software is properly installed and correctly licensed for the retail application.
The specific breach actions we see repeatedly:
Every one of those steps takes the database out of the ASFU grant and into Full Use pricing. Oracle does not need to prove intent. Its scripts detect the usage and reprice as if you never had a discount.
The highest-risk triggers are architectural, not accidental. We see out-of-scope usage most often after consolidation, virtualization, or a cloud migration that mixes ASFU and Full Use workloads on shared infrastructure. Consolidating databases onto fewer hosts is exactly what a cost-conscious infrastructure team is told to do, and it is exactly what converts a tightly discounted retail license into a full-price liability. From our engagements, roughly 1 in 3 enterprises running an ASFU-licensed application has at least one out-of-scope connection. Assume you are in that third until you have measured otherwise. For the retail-specific version of that measurement, see what an Oracle audit examines across the retail estate.
This is where the ASFU discount stops being a saving and becomes the source of the exposure. The Oracle Retail restricted-use database was cheap precisely because it was restricted. ASFU licenses are deeply discounted relative to Full Use (frequently 80 to 90 percent below list, and no less than roughly 30 to 70 percent depending on the deal). When Oracle finds an out-of-scope workload, it does not merely take back the discount on the offending piece. It prices the remediation as if you had never had a discount at all, then applies Full Use list rates to the repriced footprint.
The list numbers that drive the bill, from the Technology Global Price List effective April 16, 2026:
| Item | List price | Metric note |
|---|---|---|
| Database Enterprise Edition | $47,500 | per Processor |
| Database Enterprise Edition | $950 | per Named User Plus (25 NUP per Processor floor) |
| Standard Edition 2 | $17,500 | per occupied socket, cores ignored, max 2 sockets/server |
| Partitioning option | $11,500 | per Processor |
| Real Application Clusters (RAC) | $23,000 | per Processor |
| Multitenant option | adds on top | per Processor |
Options are where a repriced retail database gets genuinely painful. If your DBA team enabled Partitioning to speed up a Sales Audit table, or stood up RAC for availability, those options stack on top of the repriced Enterprise Edition base. In the audits we defended between 2024 and 2025 (roughly 60 to 80 Oracle license audits), unlicensed Database options accounted for 40 to 60 percent of the asserted shortfall, and backdated support plus penalty terms added another 20 to 35 percent on top of the raw license gap. Our 2026 Oracle Database cost breakdown walks the full option math with worked examples.
The good news, and it is real: those opening claims are negotiable. Across the same 2024 to 2025 audits, the opening claim ran 35 to 55 percent above the position the buyer could defend after a clean measurement. The entire gap between the vendor's opening number and the defensible number is your leverage, and it only exists if you measure first.
Oracle Retail carries two structural complications that a standalone ASFU database does not. First, several core modules are individually restricted, so a single physical database may host multiple restricted grants, each tied to a different retail application. RMS, Sales Audit, Allocation, Mobile Merchandising, and RPAS Enterprise Engine (for Merchandise Financial Planning) all use restricted licenses. If you consolidated these onto one instance and then let a schema cross the module boundary, you have created a breach even without any non-retail workload.
Second, Oracle Retail embeds third-party VAR software with its own restrictions. The MicroStrategy Components developed and licensed by MicroStrategy Services Corporation and embedded in the MicroStrategy for Oracle Retail Data Warehouse and Planning and Optimization applications carry their own use terms. Those terms do not extend your Oracle Database grant, and they do not entitle you to point MicroStrategy (or any other BI tool) at the underlying Oracle instance outside the packaged application flow.
On a consolidated retail estate the boundary you break is often between two retail modules, not between retail and non-retail. The audit exposure is identical.
There is also a support dimension that changes who you call and, therefore, what evidence exists. In an ASFU arrangement the ISV typically handles Oracle support, so if there is a database issue the customer contacts the ISV (Oracle Retail) rather than Oracle directly. That routing is fine operationally, but it means your Oracle-direct support records may be thin, which matters when you need to prove the scope of your entitlement during an audit. Keep your ordering documents and license grants filed independently of your support tickets. For the wider metric and module picture across the whole estate, the Oracle Retail Merchandising and Xstore licensing guide is the anchor reference.
If you have a genuine business need to run non-retail workloads on the same database, ASFU can be converted to Full Use through a trade-up negotiated with Oracle, where you pay the difference between the discounted ASFU price and the Full Use price. The mechanism is straightforward. The economics are where enterprises lose money. Because an existing ASFU license gives you very little leverage, Oracle typically prices the trade-up near full replacement value, effectively charging you again for a database you already own.
Do not treat trade-up as a routine fix. Treat it as a last resort, and only after you have exhausted the cheaper options: separating the non-retail workload onto its own properly licensed instance, using the retail application's built-in reporting instead of external BI, or (where the workload is modest) standing up Standard Edition 2 at $17,500 per socket rather than paying Enterprise Edition trade-up rates. The right answer is almost always architectural separation, not conversion.
The exposure is invisible by design, so the only way to know your position is to measure it before Oracle does. A defensible sequence:
If a renewal or a cloud move is on the table, fold the restricted-use question into that negotiation while you still have leverage. Our guides on negotiating an Oracle Retail renewal and capping uplift and how Oracle prices Merchandising Cloud by revenue band show where the give-and-take actually sits. The core message is simple: the retail restricted-use database is a fair deal as long as it stays inside its box. The moment you treat it as spare Enterprise Edition capacity, you have handed Oracle a repricing event, and the discount that made it attractive becomes the multiplier on the bill.
Technically yes, contractually no. It is Application Specific Full Use (ASFU), which ships the complete Enterprise Edition product with every feature working, but the license restricts you to running only the named Oracle Retail application against it. It is full use in the technical sense and application specific in the legal sense.
Only if the reporting is built into the retail application itself and uses Oracle internally. An external BI tool that queries the Oracle database directly falls outside the ASFU grant and creates an unlicensed Full Use position. Point external reporting at a separately licensed copy of the data instead.
That is the most common ASFU violation. Even though the database is correctly installed and licensed for the retail application, adding schemas for other reporting, warehousing, or applications breaches the restriction. Oracle's audit scripts detect the usage and reprice the footprint at Full Use rates, often with backdated support.
Oracle prices remediation as if the ASFU discount never existed, applying Full Use list rates (Enterprise Edition at $47,500 per Processor on the April 2026 price list) plus any options such as Partitioning ($11,500) or RAC ($23,000). In our defended audits, options drove 40 to 60 percent of the shortfall and backdated support added another 20 to 35 percent.
No. Oracle's Retail documentation states that entitled products and restricted use licenses do not apply to Oracle Retail Cloud products. If you move to the SaaS versions the restricted-use database question disappears, but revenue-band and overage metrics take its place, which changes the negotiation rather than removing it.
Only as a last resort. Trade-up is possible but Oracle prices it near full replacement value because you have little leverage, so you effectively pay again for a database you own. Architectural separation onto a correctly licensed instance, or Standard Edition 2 for modest workloads, is almost always cheaper.
Oracle Database 23ai bundles options you may never deploy. The buyer side guide to edition right sizing, option pruning, and AI Vector Search licensing.
Gated with a work email on the download page. No sales follow up you did not ask for.
Get the White Paper →
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
One buyer side briefing a week. Renewal signals, audit moves, and the levers that work. No vendor spin.
