IBM Db2 Licensing: PVU vs VPC vs Authorised User — ITAM Advisory

The Three IBM Db2 Licensing Metrics

IBM Db2 — one of the world's longest-standing enterprise relational databases — is available under three primary licensing metrics. The metric you use determines both your cost and your compliance obligations. Organisations that have inherited Db2 deployments, migrated infrastructure, or expanded into cloud and containers without revisiting their licence model are at elevated audit risk.

Processor Value Unit (PVU)

PVU is the dominant metric for on-premises Db2 deployments. IBM assigns a PVU value per core based on processor architecture: 70 PVUs for modern x86 (Intel Xeon, AMD EPYC), 100 to 120 PVUs for IBM POWER cores. The licence requirement is calculated by multiplying active cores by the per-core PVU value. A 48-core x86 server requires 3,360 PVUs; at $809 per PVU list price, a single production server represents approximately $2.72 million in ESE entitlement.

PVU operates in two modes: Full Capacity, where all physical cores on Db2 servers must be counted, and Sub-Capacity, where only virtual cores allocated to Db2 are counted. Sub-capacity is almost always significantly lower cost — but requires IBM License Metric Tool (ILMT) to be correctly deployed and reporting. Without compliant ILMT, IBM treats all PVU positions as full-capacity during an audit.

Virtual Processor Core (VPC)

VPC is the metric used in IBM's Cloud Pak for Data packaging, which delivers Db2 in containerised form for OpenShift and Kubernetes environments. VPC counts virtual CPU cores allocated to the Db2 container — no processor model weighting applies. This simplicity makes VPC well-suited to cloud-native environments where physical hardware boundaries are abstracted. However, organisations need to ensure that moving to Cloud Pak for Data's VPC model is formally supported by a licence conversion, as IBM PVU and VPC entitlements are not interchangeable.

A notable complexity in the VPC model is the bundled OpenShift entitlement within IBM Cloud Pak for Data. If an organisation already holds Red Hat OpenShift subscriptions separately, the Cloud Pak bundle may create redundant entitlements — paying for OpenShift twice. This is one of the most common unnecessary costs we identify in IBM Cloud Pak deployments.

Authorised User

The Authorised User metric licenses specific named individuals for Db2 access. It is best suited to applications with a defined, stable user population — discrete business applications, partner portals, or internal tools where access is bounded and accountable. Minimum user counts apply: five users per Db2 Workgroup Server installation, and 25 users per 100 PVUs of capacity for Enterprise Server Edition. User licensing is typically less cost-effective than PVU for large deployments or applications with many concurrent users, but can deliver material savings where the user population is genuinely small.

The risk with Authorised User licensing is silent user growth. Application teams add service accounts, API integrations connect additional systems, and the authorised user count exceeds the licensed count over time. IBM audits routinely identify Authorised User violations in organisations that have not reviewed their Db2 user count in the last two to three contract cycles.

Sub-Capacity Licensing and ILMT: The Critical Dependency

For any organisation running Db2 on virtualised infrastructure — VMware, Hyper-V, KVM, or cloud — sub-capacity PVU licensing is the most important tool for managing licence cost. But it comes with a non-negotiable condition: IBM License Metric Tool (ILMT) must be correctly deployed, actively scanning, and producing compliant reports.

IBM's Passport Advantage agreement is explicit: sub-capacity licensing is only valid where ILMT is deployed within 90 days of the first eligible product deployment and maintains a maximum scan interval of 30 days. New sub-capacity customers must implement ILMT within 90 days of their first eligible deployment on a qualifying virtualisation environment.

ILMT failures that we most commonly encounter include: ILMT installed on the tool server but not configured to scan the hosts where Db2 is running; VMware vSphere clusters that have not been registered as Eligible Virtualisation Environments in ILMT; scan reports not generated on the required schedule; and ILMT version not updated following IBM software version changes, invalidating historical scan data.

The practical financial consequence: an enterprise running Db2 sub-capacity on 10 servers, each with 40 cores, without valid ILMT reports faces a full-capacity audit exposure of 28,000 PVUs at $809 per PVU — approximately $22.6 million before any discounts. Sub-capacity at 25 percent of physical cores would be 7,000 PVUs, or approximately $5.7 million. The ILMT gap costs around $17 million in theoretical back-licensing exposure. Even accounting for negotiated discounts, this represents a material risk.

The PVU to VPC Transition: Compliance Gaps and How to Close Them

IBM's progressive transition of its product portfolio from PVU to VPC metrics — driven primarily by the Cloud Pak packaging strategy — has created compliance gaps for organisations that containerised their Db2 infrastructure without formally updating their entitlement basis. The transition is not automatic: an organisation deploying Cloud Pak for Data (VPC-metric) while retaining legacy Db2 PVU entitlements has not converted its licences — it has created a misalignment between what it owns and what it deploys.

Closing this gap requires a formal licence position review that identifies every Db2 deployment and the metric under which it should be licensed, followed by a Passport Advantage transaction to exchange legacy PVU entitlements for the appropriate VPC entitlements under the current packaging. IBM's account teams can facilitate this conversion, but the commercial terms offered at conversion are negotiable — organisations should not simply accept IBM's initial conversion proposal without independent validation.

It is also worth noting that IBM's fiscal year ends on 31 December. IBM's Software Audit Services (SAS) programme is most active in the periods surrounding year-end. Organisations that address PVU-to-VPC misalignment proactively in the second and third quarters of the year — before the audit peak — are in a materially stronger position than those who encounter an audit trigger before resolving the misalignment.

IBM Db2 Edition Compliance

Metric compliance is one dimension of Db2 licence health; edition compliance is another. IBM's audit programme will compare the features and capabilities in active use against the edition entitlement held. The most common edition violations are systematic and predictable:

• Workgroup on oversized hardware: Db2 Workgroup Server Edition is capped at 16 processor cores and 128 GB RAM. Organisations that migrated Workgroup deployments to newer, higher-specification servers often exceed these limits, creating an ESE entitlement requirement for what was considered a Workgroup deployment.
• ESE deployed with Advanced ESE features active: Database partitioning (DPF), BLU Acceleration, and pureScale are Advanced ESE features. Any organisation running these capabilities under a standard ESE entitlement is technically under-licensed for the edition.
• Development and DR instances unlicensed: IBM's standard terms require development and disaster recovery instances to be licensed unless specific contractual provisions are negotiated. These environments are commonly identified as unlicensed in IBM audits.

Choosing Your Db2 Licensing Model: A Decision Framework

The right Db2 licensing metric for your environment depends on four variables: your virtualisation or container platform, your ILMT capability, your user population structure, and your cloud deployment footprint. A practical framework:

• Virtualised on-premises with ILMT deployed: Sub-capacity PVU is the default best choice. Maintain ILMT, review scan reports quarterly, and use the sub-capacity position as the basis for renewal negotiations.
• Containerised on OpenShift/Kubernetes: Cloud Pak for Data VPC is the natural metric. Confirm the licence conversion from any legacy PVU entitlements and review the OpenShift bundling to avoid double-payment.
• Small, stable, named user population: Authorised User may be more cost-effective than PVU. Validate the user count against the current application access list and review annually.
• No ILMT and no immediate plan to deploy it: Full-capacity PVU is the only compliant option until ILMT is operational. Prioritise ILMT deployment as a cost-reduction project — the savings from unlocking sub-capacity typically cover implementation costs many times over.

Summary: What Every Db2 Licence Holder Should Know

IBM Db2 licensing has more moving parts than most enterprise database products, and the financial stakes are significant. The three metrics are not interchangeable; sub-capacity requires ILMT; the PVU-to-VPC transition is not automatic; and IBM's audit programme is active and methodical. IBM's fiscal year ends 31 December, and audit activity clusters around this period.

The organisations that manage Db2 licensing well share a common discipline: they know every deployment, they operate ILMT correctly, they review their position before IBM renewals, and they approach IBM with a documented licence position rather than accepting the vendor's opening terms. For any Db2 environment of meaningful scale, independent ITAM advisory consistently delivers better outcomes than managing the programme internally without specialist IBM licensing knowledge.