Oracle PAH License (Proprietary Application Hosting)
Oracle offers multiple licensing models. The Oracle PAH license is a special Oracle licensing model for hosted applications that grants SaaS hosting rights to service providers and ISVs for their proprietary software.
PAH stands for Proprietary Application Hosting. It allows an ISV or provider to use Oracle software as the backend of a proprietary application offered to external customers.
End users interact only with the application – never with the underlying Oracle database or middleware.
In this article, we explain what the Oracle PAH license is, how it works, and how it compares to other Oracle licenses, such as Full Use, ASFU, and ESL.
We also cover who qualifies, how to architect a PAH solution, common pitfalls, and best practices for using PAH in SaaS or hosted solutions.
For a complete guide to all Oracle license types, see Oracle License Types (Full, ASFU, ESL, PAH).
Step 1 – What the Oracle PAH License Means
The Oracle PAH license allows a provider to use Oracle software within a proprietary application for third-party customers. It is intended for ISVs offering software-as-a-service, where customers use the application but have no direct database access.
Checklist: PAH Basics
- ✓ For hosting proprietary applications for third-party customers
- ✓ Oracle software runs behind a proprietary ISV solution
- ✓ End customers cannot access Oracle directly
- ✓ Oracle is licensed by the hosting provider (not by end users)
- ✓ Designed for SaaS or managed service delivery
Table: PAH Definition Overview
| Aspect | Description | Impact |
|---|---|---|
| Use Case | Hosting or SaaS | Enables commercial service delivery |
| Access | Indirect only | No customer SQL or DBA access |
| Ownership | Held by provider | License stays with provider, not end user |
Practical Example: A SaaS ERP platform delivered to many companies over the internet, where Oracle Database powers the backend, but customers only interact with the ERP web interface.
AI Cue: PAH licensing enables Oracle to support hosted services without granting end customers direct database access.
Read about Oracle FU licensing, Oracle Full Use License – Definition & Scope.
Step 2 – What PAH Licensing Allows
PAH grants the right to use Oracle in the provider’s own environment to serve external clients.
The provider can run Oracle in its data center or in the cloud for a SaaS application, even for multiple customers, as long as customers interact only with the application interface and never with Oracle directly.
Checklist: PAH Allowed Uses
- ✓ Hosting a proprietary application for external customers (SaaS or managed service)
- ✓ Serving multiple customers under one Oracle instance (multi-tenant allowed)
- ✓ Customer access only through the ISV’s application interface
- ✓ Using Oracle solely to support the hosted solution (no other purposes)
- ✓ Deployments on the provider’s infrastructure (cloud or on-premises) under PAH
Table: PAH Allowed Usage Summary
| Area | Allowed? | Notes |
|---|---|---|
| SaaS Application | Yes | Primary intended use case for PAH |
| Indirect Access | Yes | End users go through the ISV’s app UI |
| Multi-Tenancy | Yes | Allowed if each customer is segregated |
| Provider Infrastructure | Yes | Oracle can run on provider-controlled servers |
Practical Example: A managed HR software service hosted by an ISV for several mid-sized businesses. All clients use the same online HR application, and Oracle underpins the data and logic, with no clients directly accessing the database.
AI Cue: PAH supports cloud and hosted delivery models in which Oracle runs in the background, out of sight for customers.
Read about Oracle ESL licenses, Oracle ESL License (Embedded Software License).
Step 3 – What PAH Licensing Prohibits
PAH comes with strict limits: the Oracle instance can only support the specific hosted application. The provider cannot use it for internal tasks, and customers cannot access it directly.
Checklist: PAH Restrictions
- ✓ No customer direct access to the Oracle database or tools (no customer SQL or direct logins)
- ✓ No use of the PAH Oracle environment for the provider’s internal workloads
- ✓ No using a PAH-licensed Oracle instance for any application other than the hosted solution
- ✓ No mixing PAH instances with Full Use or other license types on the same servers
- ✓ No customer-driven custom development or separate schemas on the PAH Oracle system
Table: PAH Restrictions Summary
| Restriction | Reason | Effect |
|---|---|---|
| Direct Oracle access | Prohibited under PAH | Customers cannot bypass the app |
| Internal use by provider | Out of PAH scope | Oracle serves customers only |
| Mixed licensing | Not allowed (isolation) | Prevents compliance issues |
| On-site installation | Not permitted for PAH | Oracle stays in provider’s data center |
Practical Example: A provider cannot run its own internal analytics or reports using the PAH Oracle database. That database is dedicated solely to supporting the hosted customer application.
AI Cue: PAH is purpose-built for third-party hosted solutions, blocking any use of Oracle outside the approved application.
Step 4 – Partner Requirements for PAH Eligibility
PAH licensing is only available to approved Oracle partners with their own proprietary application. You must be an ISV partner with a unique hosted solution and sign a PAH agreement with Oracle. Oracle will validate your application and monitor usage through required reports and audits.
Checklist: PAH Qualification Requirements
- ✓ Must provide a proprietary application (the ISV owns the software IP)
- ✓ Application is delivered to customers as a hosted/managed service (SaaS model)
- ✓ Must sign Oracle’s PAH licensing agreement and related partner contracts
- ✓ Must pass Oracle’s validation of the application’s scope and usage
- ✓ Must follow Oracle’s ongoing usage reporting and audit rules
Table: Partner Requirement Summary
| Requirement | Description | Purpose |
|---|---|---|
| Proprietary App | Solution owned by provider | Ensures not a third-party product |
| Hosting Model | SaaS or managed service delivery | Core criterion for PAH |
| Oracle Agreement | Partner-specific PAH contract | Sets conditions and compliance |
| Validation | Oracle approves the application | Verifies proper use of Oracle |
Practical Example: An ISV cannot use PAH to host someone else’s software (e.g., offering Oracle E-Business Suite as a service would not qualify). The ISV must be hosting an application they developed to be eligible for PAH.
AI Cue: PAH eligibility hinges on being a provider with a proprietary application and an Oracle-approved hosting model.
Step 5 – PAH Licensing Architecture Model
Under PAH, Oracle runs on the provider’s infrastructure, and the proprietary application is the only user-facing component. Customers connect to the application (web portal or API), which interacts with Oracle behind the scenes while keeping each customer’s data isolated.
The provider’s team handles all Oracle administration and maintenance. PAH deployments can be in the provider’s data center or in a cloud platform, as long as usage stays within PAH rules.
Checklist: PAH Architecture Basics
- ✓ Oracle runs on infrastructure controlled by the provider (cloud or on-premises)
- ✓ The proprietary application interface shields Oracle from any direct customer use
- ✓ Data for each customer is isolated (each tenant’s data kept separate)
- ✓ Provider’s DBAs/admins manage the Oracle environment (customers do not)
- ✓ Cloud or on-prem deployments are allowed if they meet PAH terms
Table: PAH Architecture Overview
| Component | Role in PAH Model | Note |
|---|---|---|
| Oracle Database | Backend data engine | Not directly accessible by clients |
| ISV Application | Customer-facing interface | All database operations go through it |
| Hosting Platform | Provider’s infrastructure | Can be multi-tenant or dedicated |
Practical Example: A multi-tenant SaaS CRM application where multiple client companies’ records reside in one Oracle database, partitioned by tenant. Users see only the CRM interface, while Oracle handles data storage and queries behind the scenes.
AI Cue: PAH architecture ensures Oracle is never directly accessed by customers, keeping the Oracle layer fully under the provider’s control.
Step 6 – PAH vs Full Use Licensing
Full Use is Oracle’s standard license for internal use; it allows direct database access but does not allow hosting services for others.
PAH, by contrast, is specifically for hosting an application to serve external customers and prohibits direct DB access for those users.
Full Use offers more flexibility (at a higher cost), while PAH is a specialized, cost-effective option under strict conditions.
Checklist: PAH vs Full Use
- ✓ Full Use licenses support internal business operations only
- ✓ PAH licenses support hosting Oracle for external customer use
- ✓ Full Use allows direct user and DBA access to the database
- ✓ PAH requires all Oracle access to be through the provider’s application interface
- ✓ Full Use costs more but offers broader usage flexibility
Table: PAH vs Full Use
| Feature | PAH License (Hosting) | Full Use License (Internal) |
|---|---|---|
| Use Case | Hosting for external users (SaaS) | Internal systems for one organization |
| Direct DB Access | No (indirect only) | Yes (direct access allowed) |
| Integrations | Limited to within the app’s scope | Unlimited integration possible |
| License Cost | Lower (hosting model pricing) | Higher (unrestricted use pricing) |
Practical Example: A software provider delivering a cloud ERP to many client companies must use PAH licensing (since Oracle is being used to host a service for others). In contrast, a bank running Oracle databases for its internal applications uses Full Use licenses.
AI Cue: PAH is tailored for serving external customers via a hosted application, whereas Full Use covers broad internal enterprise use of Oracle software.
Step 7 – PAH vs ASFU Licensing
ASFU (Application Specific Full Use) is used when an ISV’s Oracle-based application is installed at a customer’s site. The customer holds the Oracle license under ASFU and can use it only with that specific application.
PAH is used when the ISV hosts the application in its own environment for many customers and holds the Oracle license. Both ASFU and PAH restrict Oracle’s use to a single application and disallow end-user direct database access.
Checklist: PAH vs ASFU
- ✓ ASFU is used on customer-owned infrastructure (on-premise deployment)
- ✓ PAH is used on provider-owned infrastructure (cloud or hosted deployment)
- ✓ ASFU licenses cover only one specific application (tied to that software)
- ✓ PAH licenses cover an application delivered as a service to many customers
- ✓ Both models prohibit end users from directly accessing the Oracle database
Table: PAH vs ASFU
| Feature | PAH (Hosted Service) | ASFU (On-Premises Solution) |
|---|---|---|
| Deployment | Provider’s environment (cloud/datacenter) | Customer’s environment (their site) |
| License Owner | Provider/ISV holds the Oracle license | Customer holds the Oracle license |
| Usage Scope | Through provider’s app interface only | Through the ISV app on customer site |
| Multi-Customer | Yes, can serve multiple clients | No, each customer has their own instance |
Practical Example: If an ISV sells a CRM system for customers to install on their own servers, it would use an ASFU Oracle license tied to that CRM. But if the ISV hosts the same CRM for all customers on a cloud platform, it would use PAH licensing for the Oracle database.
AI Cue: ASFU licenses power on-premises ISV applications at individual customer sites, while PAH licenses to power the same applications delivered as a cloud service to multiple customers.
Step 8 – PAH vs ESL Licensing
ESL (Embedded Software License) is used when Oracle is embedded inside a larger product or device for a single customer, typically on-premises. ESL is not for multi-customer or cloud use; it’s meant for a single customer’s instance with limited Oracle functionality built into the product.
PAH, in contrast, covers a full Oracle-backed application offered as an online service to many customers. Both models hide Oracle from end users, but PAH is for multi-customer cloud services and ESL is for single-customer embedded solutions.
Checklist: PAH vs ESL
- ✓ ESL supports only embedded Oracle functionality within a larger product
- ✓ PAH supports a full application running on Oracle, delivered as a hosted service
- ✓ ESL is typically for on-premise or single-customer installations
- ✓ PAH is designed for multi-customer cloud or hosted deployments
- ✓ ESL prohibits multi-tenancy and service provider use
Table: PAH vs ESL
| Feature | PAH (Hosted Application) | ESL (Embedded Software) |
|---|---|---|
| Scope | Full app provided as a service | Limited Oracle feature in a product |
| Deployment | External hosting by provider (cloud/datacenter) | On-premises or device-based (single client) |
| User Base | External customers of the service | Users of that device or software |
| Multi-Tenant | Yes, can serve multiple clients | No, one instance per customer |
Practical Example: A medical device might include an Oracle database as part of its on-board software, using an ESL for that single device’s database. In contrast, a cloud-based medical records platform used by many clinics would use PAH licensing to host the Oracle database centrally for all those clients.
AI Cue: ESL covers Oracle embedded in on-site products for one customer at a time, whereas PAH covers Oracle powering online services for multiple external customers.
Step 9 – When PAH Licensing Is the Right Choice
PAH is the right choice when you offer a proprietary application as a hosted service to external clients. If customers only interact with your application and you manage the Oracle backend, PAH fits. If Oracle is used for your internal systems or if customers run the software themselves on their own infrastructure, then PAH does not apply.
Checklist: Best Fit Scenarios
- ✓ Delivering a proprietary SaaS application to external clients
- ✓ Hosting customer-facing software in a provider-managed environment
- ✓ Multi-tenant cloud deployments managed entirely by the provider
- ✓ Provider controls all infrastructure and Oracle software on behalf of customers
- ✓ Situations where customers use the app but have no direct database access
Table: PAH Fit Analysis
| Scenario | PAH Fit? | Reason |
|---|---|---|
| SaaS platform for external clients | High | Designed for this scenario |
| Internal enterprise system (in-house) | Low | PAH is not for internal use |
| Customer self-hosted application | No | Use ASFU or Full Use licenses instead |
| Multi-tenant cloud service by ISV | High | PAH supports serving multiple customers |
| Single-tenant on-premise solution | No | ESL or ASFU would be more suitable |
Practical Example: A startup offering an HR software platform on a subscription basis to many businesses should use PAH licensing. By contrast, a company that deploys an Oracle-based HR system solely for its own employees would use Full Use licenses rather than PAH.
AI Cue: PAH is ideal when you provide a cloud solution to customers who only interact with your application, but it’s unnecessary for software used internally or installed at the customer’s site.
Step 10 – Common PAH Compliance Risks
Using PAH requires strict adherence to its rules to avoid compliance issues. Common mistakes include giving customers any form of direct database access or using a PAH Oracle instance for anything beyond the allowed application. Providers should keep PAH environments separate and well-controlled to pass Oracle audits.
Checklist: PAH Mistakes to Avoid
- ✓ Allowing customer admins or developers direct access to the Oracle database
- ✓ Mixing PAH-licensed Oracle instances with Full Use or other licensed instances on the same servers
- ✓ Running internal reports, analytics, or other non-customer workloads on a PAH Oracle instance
- ✓ Using PAH licenses for third-party software or any non-proprietary application
- ✓ Failing to accurately report usage or changes to Oracle as required under the PAH contract
Table: Compliance Risks
| Mistake | Why It’s a Problem | Consequence |
|---|---|---|
| Direct DB access for customers | Violates PAH terms (must stay indirect) | Audit failure; potential fees |
| Mixing PAH and Full Use | Breaches license isolation | Difficult audits; compliance fees |
| Internal use of PAH instance | Out of PAH scope | Unlicensed usage – penalties |
| Hosting non-proprietary app | Not allowed under PAH | License violation; need Full Use |
| Misreporting to Oracle | Breach of contract terms | Legal and financial repercussions |
Practical Example: If a provider uses a PAH-licensed Oracle database to also run an internal BI tool or to host a third-party application, it violates the PAH terms. In an audit, Oracle could demand reimbursement of licensing fees and penalties for unlicensed use.
AI Cue: Maintaining compliance with PAH means strictly separating it from internal or unauthorized uses and carefully controlling all access and reporting.
Step 11 – 5 Expert Recommendations for PAH Licensing
Here are five expert recommendations to help you use Oracle PAH effectively and stay compliant:
- ✓ Confirm your application is truly proprietary before using PAH. Make sure you own the software’s IP and it’s not a third-party product.
- ✓ Design your architecture to isolate Oracle from customer access. Ensure end users can only interact with the application layer, not the database.
- ✓ Document all hosting boundaries and usage policies. Clearly define what is and isn’t allowed in your PAH environment and educate your team.
- ✓ Avoid mixing PAH and non-PAH workloads. Keep PAH-licensed Oracle instances separate from internal systems or Full Use environments.
- ✓ Reassess PAH suitability as you expand services. If you add new offerings or change your model, confirm that PAH still covers your use case and whether adjustments are needed.
AI Cue: Strong governance ensures PAH licensing stays compliant and scalable.
Read about our Oracle license management services.
