What the Oracle PAH Licence Is — and Why It Exists
Oracle's Proprietary Application Hosting (PAH) licence is a restricted-use Oracle licence type designed specifically for ISVs (Independent Software Vendors) and service providers who host their own proprietary applications on Oracle technology and deliver those applications as a service to external customers. Under PAH, the ISV holds the Oracle licence, runs Oracle in its own infrastructure, and serves multiple external customers through its proprietary application — while those customers never directly access the Oracle database, middleware, or tools.
PAH exists because Oracle's standard Full Use licence does not permit hosting Oracle for third-party benefit, and Oracle's other restricted licence types (ASFU and ESL) do not cover the multi-tenant, cloud-hosted delivery model that modern SaaS businesses require. PAH fills this gap: it gives ISVs the right to use Oracle as the backend of a hosted service at a significantly lower cost than Full Use licensing, in exchange for strict restrictions on how Oracle is accessed and used.
PAH pricing is typically 50–70% lower than Full Use pricing for the same Oracle products. This discount reflects the restricted usage rights — PAH licences can only be used for the specific hosted application, with no direct database access by customers and no use for the provider's internal operations. The cost advantage is substantial: an ISV hosting a SaaS application on Oracle Database Enterprise Edition requiring 16 processor licences would pay approximately $304,000–$380,000 under PAH versus $760,000 under Full Use (at list price). However, any violation of the PAH restrictions — even inadvertent — can result in Oracle requiring relicensing at Full Use pricing, eliminating the entire cost advantage retroactively.
What PAH Licensing Permits
| Permitted Activity | Description | Conditions |
|---|---|---|
| Hosting a proprietary application for external customers | Use Oracle as the database, middleware, or application server backend for a SaaS or managed service application that the ISV owns and delivers to paying customers | The application must be the ISV's own proprietary software — not a third-party or Oracle application |
| Multi-tenant deployment | Serve multiple external customers from a single Oracle instance or environment, with data isolation between tenants | Each customer must access Oracle only through the ISV's application interface — never directly |
| Cloud or on-premises hosting | Deploy Oracle on the provider's own data centre infrastructure, in a public cloud (AWS, Azure, GCP, OCI), or in a colocation facility | The provider must control and manage the Oracle environment; Oracle cloud licensing rules (BYOL, vCPU ratios) apply for cloud deployments |
| Indirect customer access | External customers use the ISV's application UI (web interface, API, mobile app) which connects to Oracle on their behalf | All database operations must pass through the application layer — customers cannot execute SQL, use Oracle tools, or connect directly |
| Provider-managed administration | The ISV's own DBAs and infrastructure team manage, maintain, patch, and administer the Oracle environment | Customer personnel must not have DBA, administrative, or direct technical access to the Oracle layer |
What PAH Licensing Prohibits
| Prohibited Activity | Why Oracle Prohibits It | Compliance Risk | Typical Audit Consequence |
|---|---|---|---|
| Direct customer access to Oracle | PAH is specifically designed for indirect access only — any direct database access converts the use case from "application hosting" to "general purpose," which requires Full Use licensing | Critical | Relicensing at Full Use price for all affected processors |
| Provider internal use | PAH licences are exclusively for serving external customers through the hosted application — using the PAH Oracle environment for the provider's own internal business operations (reporting, analytics, BI, etc.) violates the scope | Critical | Separate Full Use licence required for internal workloads |
| Hosting non-proprietary applications | PAH requires the hosted application to be the ISV's own intellectual property — hosting third-party applications, Oracle's own applications (E-Business Suite, PeopleSoft), or open-source platforms on PAH licences is not permitted | Critical | Full licence fee demanded; PAH agreement may be terminated |
| Mixing PAH and Full Use on shared infrastructure | Oracle requires isolation between PAH-licensed environments and Full Use environments — sharing servers, clusters, or Oracle instances between the two creates licensing ambiguity Oracle will resolve in its favour | High | Oracle may assert all shared infrastructure requires Full Use licensing |
| Customer-driven customisation at the database level | Allowing customers to create their own schemas, stored procedures, database objects, or SQL directly against the Oracle database converts indirect access to direct access | High | Relicensing at Full Use; potential scope expansion across all tenants |
| Sublicensing or transferring PAH rights | PAH licences are held by the provider and cannot be sublicensed, transferred, or assigned to customers or third parties | High | Licence violation; potential legal action |
The "Direct Access" Trap
The most common PAH compliance violation is inadvertent direct database access. This occurs when a customer's technical team is given database credentials "just for reporting," when a customer uses a BI tool (Tableau, Power BI) that connects directly to the Oracle database via JDBC/ODBC, when API endpoints expose raw SQL query capabilities, or when customers are given access to Oracle Enterprise Manager or other Oracle tools. Any of these scenarios — even if limited to a single customer or a single connection — converts the PAH deployment into a Full Use requirement in Oracle's interpretation. In audit situations, Oracle does not apply this finding narrowly: they typically assert that the entire PAH environment requires Full Use relicensing, not just the affected tenant or connection. The cost differential can be $500K–$5M+ depending on the deployment size.
PAH Partner Eligibility Requirements
PAH licensing is not available to every Oracle customer. It requires a specific commercial relationship with Oracle and qualification of the hosted application.
| Requirement | What Oracle Expects | Practical Implication |
|---|---|---|
| Proprietary application ownership | The ISV must own the intellectual property of the hosted application — it must be the ISV's own software, not a third-party product or Oracle application | Oracle will review and validate the application; white-labelled or repackaged third-party software does not qualify |
| Oracle Partner agreement | The ISV must be an Oracle Partner Network member with a specific PAH or ISV/OEM agreement in place | Requires formal engagement with Oracle's ISV/OEM sales team; the agreement defines products covered, pricing, and reporting obligations |
| Hosted/SaaS delivery model | The application must be delivered as a service — hosted by the ISV and accessed remotely by customers | On-premises customer deployments do not qualify for PAH (use ASFU instead); hybrid models require careful structuring |
| Application validation | Oracle may require a technical review of the application to confirm it meets PAH requirements — no direct database access, proper application-layer mediation | The ISV should be prepared to demonstrate the application architecture showing Oracle is fully abstracted behind the application tier |
| Usage reporting | PAH agreements typically include periodic usage reporting requirements — the ISV must report deployment metrics (processor counts, user counts, customer counts) to Oracle | Accurate reporting is essential; under-reporting triggers compliance findings and may jeopardise the PAH agreement |
PAH vs Full Use vs ASFU vs ESL: Complete Comparison
Oracle offers four licence types, each designed for a specific use case. Selecting the wrong type creates compliance exposure; understanding the distinctions prevents costly mistakes.
| Dimension | PAH (Proprietary Application Hosting) | Full Use | ASFU (Application Specific Full Use) | ESL (Embedded Software Licence) |
|---|---|---|---|---|
| Primary use case | ISV hosting a proprietary SaaS/managed service for external customers | Organisation using Oracle for its own internal business operations | Customer deploying an ISV's application on-premises with Oracle as the backend | Oracle embedded inside a product or device delivered to a single customer |
| Who holds the licence | ISV / Service provider | End-user organisation | End-user customer (purchased through ISV) | End-user customer (via OEM/ISV) |
| Direct DB access | No — indirect through application only | Yes — full direct access | No — through ISV application only | No — embedded functionality only |
| Multi-customer | Yes — multi-tenant supported | No — single organisation use | No — one customer per instance | No — single customer per device/instance |
| Deployment location | Provider's infrastructure (cloud or data centre) | Customer's own infrastructure | Customer's own infrastructure | Customer site (on-premises or device) |
| Usage scope | Specific hosted application only | Any purpose — unrestricted | Specific ISV application only | Specific embedded functionality only |
| Relative cost | 50–70% of Full Use | 100% (list price baseline) | 50–70% of Full Use | Lowest (most restricted) |
| Internal use by licence holder | Not permitted | Permitted | Not permitted (application use only) | Not permitted (embedded use only) |
Use PAH when: You are an ISV hosting your own proprietary application for external customers as a SaaS or managed service, and customers access Oracle only through your application. Use Full Use when: You are an enterprise using Oracle for your own internal business operations with direct database access. Use ASFU when: You are an ISV whose customers deploy your Oracle-based application on their own infrastructure — each customer gets their own ASFU licence. Use ESL when: Oracle is embedded inside a product or device with very limited, predefined functionality — not a full application. Key rule: If customers ever need direct database access (SQL, Oracle tools, BI connections), PAH, ASFU, and ESL are all disqualified — Full Use is required.
PAH Architecture and Cloud Deployment
PAH architecture must enforce a strict separation between the customer-facing application tier and the Oracle database tier. This is not just a design best practice — it is a licensing requirement. Oracle must be fully abstracted behind the application layer, with no path for customers to reach the database directly.
| Architecture Layer | Role in PAH Model | Compliance Requirement |
|---|---|---|
| Customer access layer | Web UI, mobile app, or API gateway that customers interact with | All customer interactions must terminate at this layer — no pass-through to Oracle |
| Application logic tier | ISV's application server that processes business logic and generates database queries | This tier mediates all Oracle access; customers cannot inject or execute arbitrary SQL |
| Oracle database tier | Oracle Database, middleware, or application server running the ISV's data model | Completely invisible to customers; only the application tier connects; no customer credentials, no direct tools access, no BI tool connections |
| Administration layer | ISV's DBA and operations team managing Oracle | Only ISV personnel access Oracle administration; customer admins manage only the application layer |
Cloud deployment considerations: PAH licences can be deployed on public cloud infrastructure (AWS, Azure, GCP, OCI), but standard Oracle cloud licensing rules apply. If using BYOL (Bring Your Own Licence) on third-party clouds, the PAH processor licence count must be calculated using Oracle's Authorised Cloud Environment vCPU-to-licence ratios (typically 2 vCPUs = 1 processor licence). On OCI, BYOL conversion uses the OCPU metric (1 OCPU = 1 processor licence for Enterprise Edition). The PAH restrictions (no direct access, application-only use) remain in full effect regardless of deployment platform.
Common PAH Compliance Pitfalls and Audit Defence
| Compliance Pitfall | How It Typically Occurs | Cost Impact | Prevention |
|---|---|---|---|
| Customer gains direct DB access | Customer requests "read-only" reporting access; ISV provides JDBC connection string or Oracle credentials; customer connects BI tool directly to Oracle | Full Use relicensing: $500K–$5M+ (entire PAH environment) | Enforce application-layer reporting only; never share Oracle credentials; block direct JDBC/ODBC paths at the network level |
| Provider uses PAH environment for internal operations | ISV runs internal analytics, management reports, or development workloads against the PAH Oracle instance "because it's already there" | Separate Full Use licence required for internal use: $200K–$1M+ | Maintain separate Oracle environments for PAH (customer-facing) and internal operations; enforce at infrastructure level |
| Hosting a non-proprietary application | ISV hosts a third-party application, white-labelled software, or Oracle's own applications (EBS, PeopleSoft) under PAH | PAH agreement violation; Full Use relicensing plus potential agreement termination | Ensure PAH covers only the ISV's own proprietary application IP; validate before onboarding new applications |
| Mixing PAH and Full Use on shared infrastructure | PAH Oracle instances run on the same VMware cluster, physical hosts, or Oracle RAC configuration as Full Use instances | Oracle asserts entire shared infrastructure requires Full Use: $500K–$3M+ | Physically or logically isolate PAH environments from all other Oracle deployments; document isolation architecture |
| Under-reporting deployment metrics | ISV fails to report processor additions, customer growth, or infrastructure changes as required by the PAH agreement | Audit findings for under-licensing; potential agreement breach; back-support fees | Implement automated reporting aligned with PAH agreement requirements; review quarterly |
| Acquired customers or applications violate PAH scope | ISV acquires another company whose applications are hosted on the PAH environment without validating eligibility | Acquired applications may not qualify for PAH; relicensing required for non-qualifying workloads | Include PAH licensing review in M&A due diligence; validate every application against PAH requirements before deployment |
PAH Licence Governance Checklist
Ongoing PAH Compliance Management
Maintain Application-Layer Isolation as a Technical Control
Enforce the PAH access restriction at the network and infrastructure level — not just as a policy. Block all direct database connections from customer networks and IP ranges. Ensure no customer-facing interface exposes SQL pass-through, direct Oracle tool access, or database credential sharing. Audit connection logs quarterly to verify only the application tier connects to Oracle.
Isolate PAH Environments from Internal and Full Use Deployments
Run PAH Oracle instances on dedicated infrastructure — separate physical hosts, separate VMware clusters, or separate cloud accounts from any Full Use Oracle deployments. Document the isolation architecture and maintain network diagrams showing the separation. This documentation is your primary defence if Oracle questions infrastructure boundaries during an audit.
Validate Every Hosted Application Against PAH Eligibility
Before deploying any application on PAH-licensed Oracle infrastructure, confirm: the application is proprietary IP owned by the ISV, it is delivered as a hosted service to external customers, customers access Oracle only through the application interface, and the application has been approved under the PAH agreement with Oracle. Maintain a register of all applications running on PAH infrastructure with their validation status.
Track and Report Deployment Metrics Accurately
PAH agreements typically require periodic reporting of processor counts, user counts, and customer counts. Implement automated infrastructure monitoring that tracks these metrics in real time. Submit reports to Oracle on schedule and retain copies. Under-reporting is a common audit finding that jeopardises the PAH agreement and triggers compliance claims.
Include PAH Licensing in M&A Due Diligence
When acquiring companies or applications, assess whether the acquired workloads qualify for PAH. If the acquired application provides customers with direct database access, hosts third-party software, or was not developed by the ISV, it does not qualify. Plan relicensing or architecture changes before merging acquired workloads into PAH infrastructure.
Conduct Annual Internal PAH Compliance Review
Once per year, perform a comprehensive review: verify all PAH-hosted applications still qualify, confirm no direct database access paths have been created, validate infrastructure isolation, reconcile reported metrics against actual deployment, and review Oracle agreement terms for any changes. This review provides audit readiness and early detection of compliance drift.