Oracle offers multiple licensing models, each designed for different deployment scenarios. The Oracle PAH licence — Proprietary Application Hosting — is a specialised model that grants SaaS hosting rights to service providers and ISVs for their proprietary software. For a complete overview of all Oracle licence types, see Oracle Licence Types (Full, ASFU, ESL, PAH).
1. What the Oracle PAH Licence Means
The Oracle PAH licence allows a provider to use Oracle software — typically Oracle Database or Oracle Middleware — as the backend of a proprietary application that is offered to external customers as a hosted service. End users interact only with the application interface. They never access the underlying Oracle database or middleware directly.
PAH is fundamentally different from Oracle's standard Full Use licence. Where Full Use supports internal business operations, PAH specifically enables commercial service delivery — hosting an Oracle-powered application for paying customers.
| Aspect | PAH Licence | Impact |
|---|---|---|
| Primary use case | Hosting a proprietary SaaS or managed application for external clients | Enables commercial service delivery on Oracle |
| Access model | Indirect only — through the provider's application interface | No customer SQL, DBA access, or direct database connections |
| Licence ownership | Held by the provider (ISV), not the end customer | Provider is responsible for Oracle compliance and reporting |
| Oracle products covered | Oracle Database, Middleware (WebLogic, etc.), and other specified products | Each product must be explicitly covered under the PAH agreement |
| Multi-tenancy | Permitted — multiple customers can share one Oracle instance | Data isolation between tenants is the provider's responsibility |
2. What PAH Licensing Allows
PAH grants the right to use Oracle in the provider's own environment — data centre or cloud — to serve external clients. The provider can run Oracle for a SaaS application, even serving multiple customers, as long as all customer interaction happens through the application interface.
| Allowed Use | Description | Conditions |
|---|---|---|
| SaaS application delivery | Hosting a proprietary app for external customers | Primary intended PAH use case |
| Multi-tenant deployments | Serving multiple customers from one Oracle instance | Each customer's data must be isolated |
| Cloud infrastructure | Running Oracle on the provider's cloud platform | Must comply with Oracle's cloud licensing policies |
| On-premises hosting | Running Oracle in the provider's data centre | Standard PAH architecture rules apply |
| Managed service delivery | Providing Oracle-backed managed services to clients | Clients access only through the provider's application |
The provider's team handles all Oracle administration, patching, and maintenance. Customers never interact with Oracle directly — they use only the application's web portal, API, or other interface provided by the ISV.
Need guidance on structuring your PAH agreement with Oracle?
Oracle Contract Negotiation →3. What PAH Licensing Prohibits
PAH comes with strict boundaries. The Oracle instance can only support the specific hosted application. The provider cannot use it for internal purposes, and customers cannot access Oracle directly under any circumstances.
- No direct Oracle access for customers. Customers cannot use SQL*Plus, SQL Developer, Oracle Enterprise Manager, or any other tool to connect to the Oracle database. All access must flow through the application interface.
- No internal use by the provider. The PAH-licensed Oracle environment is dedicated to serving external customers. The provider cannot run internal analytics, reports, HR systems, or any other internal workload on the PAH instance.
- No use for other applications. The Oracle instance must serve only the specific proprietary application identified in the PAH agreement. Running a second application — even another product owned by the same ISV — is not permitted without a separate licence.
- No mixing of licence types. PAH-licensed Oracle instances must be isolated from Full Use, ASFU, or ESL instances. Mixing licence types on the same server creates compliance issues that are extremely difficult to resolve in an audit.
- No customer-driven custom development. Customers cannot create their own schemas, write custom SQL, or develop extensions that bypass the application layer. Any custom development must happen within the application's own framework.
4. Partner Requirements for PAH Eligibility
PAH licensing is not available to every organisation. Oracle restricts PAH to approved partners who meet specific criteria — primarily, you must be an ISV with a proprietary application that you deliver as a hosted service.
| Requirement | Description | Why Oracle Requires It |
|---|---|---|
| Proprietary application | The ISV must own the intellectual property of the hosted software | Ensures PAH is not used to resell Oracle access directly |
| Hosted delivery model | The application must be delivered as SaaS or a managed service | Core criterion that distinguishes PAH from other licence types |
| Oracle partner agreement | Must sign Oracle's PAH-specific licensing agreement | Sets conditions, reporting requirements, and audit rights |
| Application validation | Oracle reviews and approves the application's scope and usage | Verifies the application qualifies for PAH terms |
| Ongoing reporting | Provider must report usage to Oracle as required under the PAH contract | Enables Oracle to monitor compliance and audit if needed |
5. PAH Licensing Architecture Model
Under PAH, the architecture must enforce a clean separation between Oracle and the end customer. Oracle runs on the provider's infrastructure, and the proprietary application is the only component that customers interact with. The provider's DBAs manage all Oracle administration.
| Layer | Role in PAH Architecture | Who Manages It |
|---|---|---|
| Customer-facing application | Web portal, API, mobile app — the only interface customers see | Provider/ISV |
| Application logic layer | Business rules, data processing, workflow engines | Provider/ISV |
| Oracle Database / Middleware | Backend data storage, query processing, transaction management | Provider's DBAs (customers have zero access) |
| Hosting infrastructure | Servers, storage, networking — cloud or on-premises | Provider/ISV |
In a multi-tenant deployment, multiple customer organisations can share a single Oracle instance. The provider is responsible for ensuring data isolation between tenants — typically through schema separation, row-level security, or application-level partitioning. Oracle does not mandate a specific multi-tenancy approach, but the provider must be able to demonstrate proper isolation during an audit.
A mid-market ERP provider delivers its proprietary application to 200+ client companies using a single Oracle Database Enterprise Edition instance. Each client's data is isolated by schema. Customers access only the ERP web interface — no one outside the provider's DBA team can reach the Oracle database. The provider holds PAH licences covering the full Oracle environment and reports usage to Oracle quarterly. This architecture has passed two Oracle audits without findings.
Need Help Structuring Your PAH Architecture?
Our Oracle advisory team helps ISVs and SaaS providers design compliant PAH architectures, negotiate PAH agreements with Oracle, and prepare for audits.
6. PAH vs Full Use Licensing
Full Use is Oracle's standard licence for internal business operations. It allows unrestricted access to Oracle — including direct database connections, custom SQL, integrations with third-party systems, and use across any internal application. PAH, by contrast, is purpose-built for hosting a proprietary application for external customers.
🏢 Full Use Licence
- ✅ Internal business operations
- ✅ Direct database access (SQL, DBA)
- ✅ Unlimited integrations
- ✅ Any internal application
- ❌ Cannot host for third parties
- 💰 Higher list price
☁️ PAH Licence
- ✅ Hosting for external customers
- ❌ No direct customer DB access
- ❌ Limited to one hosted application
- ❌ No internal use by provider
- ✅ Multi-tenant SaaS delivery
- 💰 Lower cost (hosting model pricing)
The cost difference can be significant. PAH licences are typically priced lower than Full Use because Oracle restricts how the software can be used. However, if your deployment violates PAH terms, Oracle can require retroactive reclassification to Full Use pricing — a potentially expensive correction.
7. PAH vs ASFU Licensing
ASFU (Application Specific Full Use) and PAH are both ISV-oriented licence types, but they serve different deployment models. ASFU is used when Oracle is installed at the customer's site. PAH is used when Oracle runs in the provider's environment, serving customers remotely. For full ASFU details, see Oracle ASFU Licence (Application Specific Full Use).
| Factor | PAH (Hosted Service) | ASFU (On-Premises) |
|---|---|---|
| Deployment location | Provider's environment (cloud/data centre) | Customer's environment (their site) |
| Licence holder | Provider/ISV holds the Oracle licence | Customer holds the Oracle licence |
| Multi-customer | Yes — can serve many clients from one instance | No — each customer has their own instance |
| Oracle usage scope | Through provider's application interface only | Through the ISV application on customer site only |
| Direct DB access | Prohibited for customers | Prohibited for customers |
| Typical pricing | Lower (hosting model) | Discounted vs Full Use (bundled with ISV app) |
8. PAH vs ESL Licensing
ESL (Embedded Software Licence) is used when Oracle technology is embedded inside a larger product, typically for a single customer on-premises. ESL provides the most restricted Oracle access and the lowest cost. For full ESL details, see Oracle ESL Licence (Embedded Software Licence).
| Factor | PAH (Hosted Application) | ESL (Embedded Software) |
|---|---|---|
| Scope | Full application delivered as a service | Limited Oracle functionality embedded in a product |
| Deployment | Provider's cloud/data centre (external hosting) | On-premises or device-based (single client) |
| Multi-tenancy | Yes — can serve multiple clients | No — one instance per customer |
| Oracle features available | Full Oracle capabilities as needed by the application | Only a predefined, narrow set of Oracle functions |
| End-user DB access | None (indirect through application only) | None (Oracle is hidden within the product) |
| Cost | Mid-range (hosting model pricing) | Lowest (typically ~10% of list price) |
The fundamental difference: ESL is for single-customer, on-premises, embedded use where Oracle is essentially invisible. PAH is for multi-customer, hosted use where Oracle powers a full application delivered as a service. If your product is a physical device or appliance with an embedded database, ESL is the right model. If your product is a cloud application serving many customers, PAH is the right model.
9. PAH in Cloud Environments
PAH deployments are increasingly running on public cloud infrastructure — AWS, Azure, GCP, or Oracle Cloud (OCI). Oracle permits PAH deployments in cloud environments, but the provider must comply with both PAH terms and Oracle's cloud licensing policies simultaneously.
| Cloud Factor | PAH Consideration |
|---|---|
| vCPU/OCPU counting | Standard cloud licensing rules apply — 2 vCPUs = 1 Processor licence on AWS/Azure; OCPU-based on OCI |
| Auto-scaling | If your application auto-scales Oracle instances, you must licence the maximum potential vCPU count |
| BYOL on cloud | PAH licences can be used in BYOL mode on authorised cloud platforms |
| OCI advantages | OCI offers the most favourable Oracle licensing terms — 1 licence per OCPU vs 1 licence per 2 vCPUs on AWS |
| Isolation requirement | PAH instances must remain isolated from any non-PAH workloads, even in the cloud |
For detailed guidance on Oracle cloud licensing rules, see our guides on Oracle Licensing on AWS and Oracle BYOL on OCI.
10. When PAH Licensing Is the Right Choice
PAH is the right licence type when you deliver a proprietary, Oracle-backed application as a hosted service to external customers who never access Oracle directly. If any of those conditions do not apply, a different licence type is more appropriate.
| Scenario | PAH Fit | Reason |
|---|---|---|
| Multi-tenant SaaS platform for external clients | ✅ High | Primary designed use case for PAH |
| ISV-hosted managed application service | ✅ High | Provider controls Oracle, customers use the application only |
| Internal enterprise system (own employees) | ❌ No | PAH is not for internal use — Full Use required |
| Customer self-hosted on-premises application | ❌ No | Use ASFU or Full Use instead |
| Embedded Oracle in a device or appliance | ❌ No | ESL is the correct model for embedded use |
| Hosting Oracle E-Business Suite for clients | ❌ No | E-Business Suite is Oracle's product — PAH requires a proprietary application |
| Offering direct Oracle database access as a service | ❌ No | PAH prohibits direct database access — Full Use needed |
Not sure which Oracle licence type fits your business model?
Oracle Advisory Services →11. Common PAH Compliance Risks
PAH compliance requires strict adherence to its terms. The most dangerous violations involve allowing any form of direct Oracle access or using the PAH environment for purposes outside its designated scope.
| Compliance Mistake | Why It Violates PAH | Typical Audit Consequence |
|---|---|---|
| Customer admin gets direct DB access (even read-only) | PAH mandates all access through the application layer | Reclassification to Full Use pricing — potentially millions in back-licensing |
| Provider runs internal workloads on the PAH instance | PAH is exclusively for serving external customers | Unlicensed internal usage — audit penalty plus Full Use licence purchase |
| Mixing PAH and Full Use on the same server | Licence isolation is required — mixing creates ambiguity | Oracle may claim the entire server requires Full Use licensing |
| Hosting a third-party application (not provider's own IP) | PAH requires a proprietary application owned by the provider | Entire PAH licence disqualified — Full Use required for all deployments |
| Failing to report usage to Oracle | PAH agreements include reporting obligations | Breach of contract — may trigger audit and loss of PAH pricing |
| Expanding to a second application without separate licence | Each PAH agreement covers a specific application | Second application is unlicensed — requires new PAH or Full Use purchase |
A SaaS analytics provider held PAH licences for its proprietary platform. During growth, the product team added a feature allowing enterprise clients to run custom SQL queries against a reporting replica of the Oracle database. This direct database access violated PAH terms. During a routine Oracle audit, the finding triggered a reclassification demand to Full Use pricing across the entire deployment, resulting in a multi-million-dollar compliance claim. With expert advisory support, the provider restructured the reporting feature to use application-layer APIs, restored PAH compliance, and negotiated the claim down significantly.
Facing an Oracle Audit? Protect Your PAH Deployment.
Our audit defence team has reduced Oracle compliance claims by 60–95% across hundreds of engagements — including complex PAH and ISV licensing scenarios.
12. Expert Recommendations for PAH Licensing
- Confirm your application is truly proprietary before pursuing PAH. You must own the software's intellectual property. Hosting Oracle's own applications (EBS, PeopleSoft, etc.) for third parties does not qualify for PAH.
- Design your architecture to enforce zero direct Oracle access. Build the application layer as the only gateway to Oracle. No SQL tools, no JDBC connections from customer environments, no SSH tunnels to the database server. Make this enforceable through network security, not just policy.
- Keep PAH environments strictly isolated. Do not mix PAH-licensed Oracle instances with Full Use or internal systems on the same infrastructure. Separate clusters, separate servers, separate cloud accounts if possible. Isolation simplifies audit defence enormously.
- Document everything. Maintain clear records of your PAH architecture, customer access controls, Oracle licence inventory, and usage reports. When Oracle audits — and they will — documentation is your primary defence.
- Reassess PAH suitability as your business evolves. If you add new product lines, enter new markets, or change your service delivery model, verify that PAH still covers your use case. A business model shift from SaaS to on-premises delivery may require transitioning to ASFU or Full Use licences.
- Negotiate PAH terms carefully with Oracle. PAH agreements contain specific clauses around pricing, reporting, audit rights, and renewal. Have an independent licensing expert review the agreement before signing. See our Oracle Contract Negotiation Service for support.
Get Independent PAH Licensing Guidance
Our Pay-When-We-Save™ model means we earn our fee from the savings we deliver. No savings, no fee. Vendor-independent. No ties to Oracle.
Frequently Asked Questions
Oracle Licensing & Advisory Services
Need Expert Oracle Licensing Guidance?
Our Oracle advisory team has managed 200+ licensing engagements for Fortune 500 companies. Vendor-independent. Fixed-fee engagements. No ties to Oracle.